身份验证处理后，Chrome不会重定向回URL [英] Chrome won't redirect back to URL after Authentication handling

问题描述

至少两年来，我一直在MVC解决方案中使用与此类似的代码...

  [授权]公共类HomeController:控制器{[HttpGet]公共ActionResult Index(){..... 

然后输入我的验证码

  myAuthenticationProperties =新的Microsoft.Owin.Security.AuthenticationProperties();myAuthenticationProperties.AllowRefresh = true;myAuthenticationProperties.ExpiresUtc = DateTime.UtcNow.AddMinutes(60);myAuthenticationManager.SignIn(myAuthenticationProperties，myClaimsIdentity);返回RedirectToAction("Index"，"Home"); 

在我的创业公司中.

 公共无效配置(IAppBuilder应用){CookieAuthenticationOptions myAuthOptions =新的CookieAuthenticationOptions();myAuthOptions.AuthenticationType ="ApplicationCookie";myAuthOptions.CookieHttpOnly = true;myAuthOptions.SlidingExpiration = true;myAuthOptions.LoginPath = new PathString("/Authentication/LogIn");//这是为Owin Cookie修复"添加的内容myAuthOptions.CookieSameSite = SameSiteMode.Strict;myAuthOptions.CookieSecure = CookieSecureOption.Always;app.UseCookieAuthentication(myAuthOptions);} 

直到现在，生活一直很花哨.我一直到处乱走，试图找出为什么当我尝试登录时有时可以正常工作，而有时却只是挂起.使用一些调试消息，我发现我的身份验证过程已完成，但是当发生RedirectToAction时，什么也没有发生..只是挂起.

然后我有了一个突破，我尝试使用IE和Edge，它似乎每次都起作用.只有Chrome挂起，并且挂起的时间至少为75％.

**更新**

我同时使用了Fiddler和Chrome的Debugging(控制台"和网络"选项卡)，当RedirectToAction发生时，就该网站而言，它已经完成.但是，根据Fiddler和Chrome的网络"，什么也没有，也没有任何意思，会通过网络返回到我的客户端.

但是，如果我手动更改网址以返回家，Chrome感到很高兴，我现在已经通过身份验证，并且我的[Authorize]现在允许加载控制器.

我已经研究了新的Chrome Cookie内容，尽管修复"似乎很泥泞，但我还是找到了一个使用代码来强制SameSite Cookie报告除LAX之外的内容的人.我实现了该功能，实际上将其设置为严格"，但是... Chrome挂起.

**创可贴**

我不知道这要花多少时间，但是我通过使用Javascript计时器来解决了这个问题，该计时器在用户单击提交"按钮时启动，计时器等待6秒，然后重定向回到首页/索引.

如果问题不存在(IE，Edge)，则客户端会在计时器有机会抓住机会之前自动重定向.如果他们使用的是Chrome并决定挂起，则6秒钟后，它的行为就好像他们的浏览器很慢一样，也会将他们带到正确的位置.

**固定(也许)**

因此，即使看不到返回到客户端的网络流量，我还是结束了(除了上面的创可贴之外)，进行了一些其他更改，因此现在Owin和Asp.net cookie都报告了安全和sameSite =严格.这似乎与我的问题有所不同，并且在仍然要挂起的情况下，我的定时重定向可以解决问题.

对于那些也可能遇到这种奇怪情况的人，Cookie修正的要旨是...

1. 更新您的Owin软件包，以确保您使用的是4.1版
2. 将Startup.cs中的CookieAuthenticationOptions调整为我在上面添加的项目，以使Owin Cookie兼容.

3. 在您的Web.config中更新以下内容，以使您的Asp.net Cookie兼容

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

做这三件事(以及在SSL下运行项目)将导致Chrome将Cookie分别报告为安全"和严格".

解决方案

Google更改了

正式发布时间是IIRC 2月4日，但他们正在分阶段推出以判断引起的问题.

一些资源:
Microsoft ASP.有关即将发生的更改的NET博客/铬博客/

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.

解决方案

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

这篇关于身份验证处理后，Chrome不会重定向回URL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！