This is starting to look like this issue, which also randomly started happening: https://support.aspnetzero.com/QA/Questions/8783/Login-Loop---Chrome-Fails---IE-Working---Hosted-In-IIS
I was not able to figure it out. What's most confusing is that it works fine for the my Production website in the same version of Chrome. Smells like some weird Chrome bug.
No, this is the only ABP project I am working on. Good to know about Chrome. It's not the first time I have seen something weird like this with Chrome.
Never mind, I think the problem is with Chrome caching. I have no idea what it's going, but it's using some aggressive caching techniques. I tried Private Mode and the issue persists. Then I tried IE and it works completely fine. Anyone else seen this issue?
I was happily running the website locally this morning, but all of a sudden, it cannot log in anymore, using any account. I checked my change history and nothing has really changed that could cause this. I also reverted back to the code that is in Production and that doesn't work either. Production on Azure thankfully works, but my Staging slot in Azure does not work even though it worked just fine this morning (I did not change the code). Furthermore, I have another laptop that has code that is about 2 weeks old. I just ran that and it does not log in, so something very shady is going on. Something somewhere on the internet is down, but I don't know what.
I stepped through the AccountController's Login method and it works fine, it returns success. Putting in the wrong password returns failure. But something is not working as far as maybe setting the AbpSession, as /api/services/app/Session/GetCurrentLoginInformations returns a null user. The cookie itself is there in the browser, I checked. I am not too familiar with how AbpSession works, so if you tell me where to set a breakpoint to see if it's getting set properly, I can do it.
So, there must be something external that either Abp or AspNetZero are accessing that stopped working between now and this morning.
Just chiming in here. I purchased AspNetZero for a smaller project and it's working great, but right now I am starting another project which is much more complicated. Javascript is my least favorite thing in the world and I shudder at the thought of having to debug another line of JS. Blazor is the only thing out there that really solves this problem. I am looking forward to news on this topic.
I will try that. Thank you!
No, I am not sure why this may be happening. It is very sporadic and is happening only a handful of times per day. I have a lot of users.
I see the following crash in OnStart on Android for a handful of my users. I cannot reproduce this myself. Has anyone seen this? Why would it not be able to resolve the INavigationService dependency? The only call to the DependencyResolver in OnStart is await DependencyResolver.Resolve<INavigationService>().InitializeAsync();.
android.runtime.JavaProxyThrowable: at BalanceForecasting.Core.Dependency.DependencyResolver.Resolve[T] () [0x00006] in <da884dc937844bcb825aea050968506b>:0
at BalanceForecasting.App.OnStart () [0x000a6] in <da884dc937844bcb825aea050968506b>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.<ThrowAsync>b__7_0 (System.Object state) [0x00000] in <7d466fc78986465b98bf8e069ca47b5e>:0
at Android.App.SyncContext+<>c__DisplayClass2_0.<Post>b__0 () [0x00000] in <c2c0528935f749b79020cc27a8a55d69>:0
at Java.Lang.Thread+RunnableImplementor.Run () [0x00008] in <c2c0528935f749b79020cc27a8a55d69>:0
at Java.Lang.IRunnableInvoker.n_Run (System.IntPtr jnienv, System.IntPtr native__this) [0x00009] in <c2c0528935f749b79020cc27a8a55d69>:0
at (wrapper dynamic-method) Android.Runtime.DynamicMethodNameCounter.30(intptr,intptr)
at mono.java.lang.RunnableImplementor.n_run (Native Method)
at mono.java.lang.RunnableImplementor.run (RunnableImplementor.java:30)
at android.os.Handler.handleCallback (Handler.java:883)
at android.os.Handler.dispatchMessage (Handler.java:100)
at android.os.Looper.loop (Looper.java:214)
at android.app.ActivityThread.main (ActivityThread.java:7356)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:492)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:930)
No, it is an issue with Flurl specifically not supporting Http 2.0. Once I change the Azure website back to Http 1.1, everything works fine. So I will just use 1.1 for now.