Hello,
We are experiencing issues Authenticating users after Chrome updated to 84.0.4147.105 on Windows Desktop applications.
In the Windows user's AppData folder for Chrome, there is a file named "Local State" that when deleted, Chrome regenerates the file and we are able to authenticate all the way through to the App dashboard.
If this file remains, the application does not fully authenticate the user and redirect to the portal dashboard, instead will bring you back to the log in prompt.
Without requiring our portal users to delete this file, is there a method that we can use to reset the application's interaction with the "Local State" File found at the path below?
C:\Users<user account>\AppData\Local\Google\Chrome\User Data\Local State
This only affecting users that have previously logged in before the update (presumably), restarted their machine, and logged in to their windows user profile on their PC. If a different user profile exists on the same machine, but has not logged into a ASP.NET - Zero application, the user can successfully log in.
All other browsers work.
24 Answer(s)
-
0
I'm seeing this as well. Jquery / 8.9
New deployment and when setting up new tenant, gets into a login loop.
Works with MS Edge, but some Chrome installations get in this authentication loop.
I'm actively troubleshooting it at this very moment.
-
0
@URITECHNOLOGY - what version are you on? JQ or Ang?
I'm still trying to recreate this in my dev environment using a local state file, but not having much luck.
-
0
@URITECHNOLOGY - was the URL it redirected you to %2fApp ?
I see that in our URLs - and I'm thinking, for some reason that's getting changed.
I'm wondering if something in the upgrade affects how Chrome handles the redirect.
-
1
No progress here - I'm going to watch github and see if an issue is opened on ANZ or ABP.
This is bad.
-
0
FWIW - We had two factor enabled the first time the user logged in, then disabled it.
Were you using two factor at all?
-
0
@marble68
We are using JQ 8.9. It is redirecting to %2fApp. We are not using MFA or two factor.
It is not logging all the way in, no .AspNetCore.Identity.Application Cookie is set.
Only when that file named "Local State" is regenerated will it complete the log in.
One of the objects in the file (hard to tell which one exactly) is probably persisting the session token from before the update.
-
0
so removing the file worked for one user, but not another.
hopefully someone from support has seen this.
-
0
looked at the apb code and found nothing that jumps out at me, either.
theres definantly something broken with ANZ and new Chrome.
ive done zero mods to authentication.
-
0
are you seeing it even post to controller methods?
-
0
We are seeing a 302 (redirect) response to /App so it is posting.
We have made zero changes to Authentication.
-
0
This seems to be on a User profile basis. I can log on to another profile in windows and open chrome to complete auth.
-
0
Internally it is calling the authentication controller using http which is breaking in chrome.
We manually set the cookie to https to bypass the strict, but its breaking the impersonation functionality because it is persisting through the session..
Below is what we are using to bypass the Strict policy set by Google Chrome
var cookieOptions = new CookiePolicyOptions { MinimumSameSitePolicy = SameSiteMode.None }; app.UseCookiePolicy(cookieOptions);
We need an example of how to set the cookie properly or figure out a configuration setting to redeploy the app using Chrome 80+.
All of our apps have been configured with HTTPS and strict secure.
-
0
Good find!
I've got a user that's trying to setup their machine for me to remote into so I can push / debug. Luckily, we're not live yet so I have a production environment on Azure to work with.
-
0
However, I really wish someone from support would offer some suggestions.
Have you opened a ticket on gitHub yet?
-
0
Is this your dev environment? If so - do you know a way to recreate the issue on a machine that doesn't have the problem? I tried taking a Local State file from a user's machine that had the issue but it didn't work. Perhaps it's my profile. I'll try using the local state file and hitting my production and trying to login as an affected user.
I can't recreate in dev, so I'm feeling around in the dark here.
-
0
By the way - my server does NOT have SSL enabled right now - so it's pure http and I'm having same problem.
I finally was able to recreate against my azure production server (with no SSL currently installed) by using an affected Local State file.
I'll update here if I learn anything.
-
0
So here's what I've found in my logs:
result.Succeeded, sending Microsoft.AspNetCore.Mvc.JsonResult Executing JsonResult, writing value of type 'Abp.Web.Models.AjaxResponse'. Executed action XXXXXX.Web.Controllers.AccountController.VerifySecurityCode (XXXXXX.Web.Mvc) in 378.4956ms Executed endpoint 'XXXXXX.Web.Controllers.AccountController.VerifySecurityCode (XXXXXX.Web.Mvc)' Request finished in 414.1965ms 200 application/json; charset=utf-8 Request starting HTTP/1.1 GET http://YYYYYYYYYYYYYYY/App Authorization failed. AuthenticationScheme: Identity.Application was challenged. Request finished in 12.6433ms 302 Request starting HTTP/1.1 GET http://YYYYYYYYYYYYYYY/Account/Login?ReturnUrl=%2FAppAuthorization Failed on the App request
-
0
So I was finally able to get this running in debug.
had to modify IIS Express config, hosts file, etc.
But this failure is happening somewhere deep; maybe in something closed source?
-
0
We're going to need someone from support to resolve this - It authenticates, redirects to app - and somewhere inside ABP or the ANZ modules, the following tems get logged and it redirects from App back to login.
INFO 2020-07-31 18:35:18,271 [24 ] uthorization.DefaultAuthorizationService - Authorization failed. INFO 2020-07-31 18:35:18,271 [24 ] tion.Cookies.CookieAuthenticationHandler - AuthenticationScheme: Identity.Application was challenged. -
0
Also, on my end, no user can login to my tenant, regardless of profile.
-
0
BTW - in looking at ABP code - I'm wondering if this is related:
-
0
https://support.aspnetzero.com/QA/Questions/8783/Login-Loop---Chrome-Fails---IE-Working---Hosted-In-IIS
@marble68 Above is the fix.
var cookieOptions = new CookiePolicyOptions { MinimumSameSitePolicy = SameSiteMode.None }; app.UseCookiePolicy(cookieOptions);If you apply the above code with and use a self-signed SSL cert for local development, it will work and impersonation will also work.
-
0
It would be great to have some one from the support team comment on this to ensure that this is the fix before we deploy.
-
0
hi @URITECHNOLOGY and @marble68
You can refer to this issue.
https://github.com/aspnetzero/aspnet-zero-core/issues/2950
