Chrome won't redirect back to URL after Authentication handling

问题

For at least a couple of years, I've been using code similar to this in my MVC solutions...

[Authorize]
public class HomeController : Controller
{
    [HttpGet]
    public ActionResult Index()
    {
          ..........

Then in my Authentication code

myAuthenticationProperties = new Microsoft.Owin.Security.AuthenticationProperties();
myAuthenticationProperties.AllowRefresh = true;
myAuthenticationProperties.ExpiresUtc = DateTime.UtcNow.AddMinutes(60); 
myAuthenticationManager.SignIn(myAuthenticationProperties, myClaimsIdentity);

return RedirectToAction("Index", "Home");

And in my Startup..

    public void Configuration(IAppBuilder app)
    {
        CookieAuthenticationOptions myAuthOptions = new CookieAuthenticationOptions();
        myAuthOptions.AuthenticationType = "ApplicationCookie";               
        myAuthOptions.CookieHttpOnly = true; 
        myAuthOptions.SlidingExpiration = true; 
        myAuthOptions.LoginPath = new PathString("/Authentication/LogIn");

        //This is what was added for the Owin cookie "fix"
        myAuthOptions.CookieSameSite = SameSiteMode.Strict;                                 
        myAuthOptions.CookieSecure = CookieSecureOption.Always;


        app.UseCookieAuthentication(myAuthOptions);
    }

And life has been dandy... until now. I've been chasing my tail all over the place trying to figure out why when I attempt to log in, sometimes it works, and other times it just hangs. Using some Debug Messages, I found that my Authentication process finishes, but when the RedirectToAction occurs, nothing happens.. just hangs.

Then I had a break through, I tried using IE and Edge and it seems to work every time. Only Chrome hangs and it does it at least 75% of the Time if not more.

** UPDATE **

I have used both Fiddler and Chrome's Debugging (Console and Network tabs) and when the RedirectToAction occurs, as far as the website is concerned it is done. However nothing, and I mean nothing, comes back on the network to my client (according to Fiddler and Chrome's Networking).

Yet, if I manually change the url to go back home, Chrome is happy, I'm now authenticated and my [Authorize] now allows the controller to load.

I have looked into the new Chrome cookie thing, and although the "fix" seems to be as clear as mud, I was able to find someone who used code to force the SameSite cookie to report something other than LAX. I implemented that, actually having it set to "Strict" and still.... Chrome Hangs.

** The Band-Aid **

I don't know how much time this is going to buy me, but I have kludged the problem by using a Javascript timer that when the user clicks the submit button, the timer starts, waits 6 seconds, and then redirects back to the Home/Index.

If the issue isn't there (IE, Edge) the Client redirects automatically before the timer gets a chance to take hold. If they are using Chrome and it decides to hang, 6 seconds later it will behave as if their browser is just slow and will also take them to the correct place.

** Fixed (maybe) **

So even though no network traffic can be seen coming back to the client, I ended up (in addition to my band-aid above), implementing some additional changes so now both the Owin and Asp.net cookies are reporting Secure and sameSite = Strict. This seems to make a difference with my problem, and in cases where it still wants to hang, my Timed re-direct finishes off the problem.

For those that may experience this oddity as well, the gist of the Cookie fix is this...

1. Update your Owin packages to make sure you are using version 4.1
2. Adjust your CookieAuthenticationOptions in your Startup.cs to the items I added above to make the Owin cookie compliant.

3. Update the following in your Web.config to make your Asp.net cookie compliant

   <system.web>
      <sessionState cookieSameSite="Strict" />
      <httpCookies requireSSL="true" />
   </system.web>
   

Doing those 3 things, (along with running your project under SSL) will result in Chrome reporting both cookies as Secure and Strict.

回答1:

Google made a change to how Chrome handles cookies without the SameSite attribute. Before, Chrome treated not having the SameSite attribute set on a cookie as the same as having SameSite=None, which meant the browser would accept all cookies. Now, they're treating it as having SameSite=Lax, which will only accept cookies from the same domain. To get the same effect as the old method, the attribute must be set as SameSite=None; Secure.

I can't tell if this is what's impacting you, but if this is the case you'll see an error in the Chrome console.

The official release was February 4th IIRC, but they're doing a phased rollout to judge an issues being caused.

Some resources:
Microsoft ASP.NET blog about the upcoming changes / Archived copy
Chromium Blog / Archived Copy

来源：https://stackoverflow.com/questions/60196931/chrome-wont-redirect-back-to-url-after-authentication-handling