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
@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
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
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=%2FApp
Authorization Failed on the App request
-
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
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.