Chrome 不会在身份验证处理后重定向回 URL

Chrome won't redirect back to URL after Authentication handling

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

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

然后在我的验证码中

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

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

在我的初创公司中..

    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);
    }

生活一直很美好……直到现在。我一直在到处追赶我的尾巴,试图弄清楚为什么当我尝试登录时,有时它有效,而其他时候它只是挂起。使用一些调试消息,我发现我的身份验证过程完成了,但是当 RedirectToAction 发生时,没有任何反应..只是挂起。

然后我有了突破,我尝试使用 IE 和 Edge,似乎每次都有效。只有 Chrome 挂起,并且至少有 75% 的时间挂起。

** 更新 **

我同时使用了 Fiddler 和 Chrome 的调试(控制台和网络选项卡),当 RedirectToAction 发生时,就网站而言它已经完成。然而,什么也没有,我的意思是没有,在网络上返回到我的客户端(根据 Fiddler 和 Chrome 的网络)。

然而,如果我手动更改 url 回家,Chrome 很高兴,我现在已经通过身份验证并且我的 [Authorize] 现在允许加载控制器。

我已经研究了新的 Chrome cookie 的东西,虽然 "fix" 看起来像泥一样清晰,但我找到了使用代码强制 SameSite cookie 的人报告 LAX 以外的内容。我实现了它,实际上将它设置为 "Strict" 并且仍然...... Chrome 挂起。

** Band-Aid **

我不知道这能给我多少时间,但我通过使用 Javascript 计时器解决了这个问题,当用户单击提交按钮时,计时器启动,等待 6秒,然后重定向回 Home/Index.

如果问题不存在(IE、Edge),客户端会在计时器有机会计时之前自动重定向。如果他们正在使用 Chrome 并且它决定挂起,6 秒后它会表现得好像他们的浏览器只是很慢并且也会将他们带到正确的地方。

** 固定(可能)**

因此,即使看不到网络流量返回客户端,我最终(除了上面的 band-aid 之外)实施了一些额外的更改,所以现在 Owin 和 Asp.net cookies 正在报告 Secure 和 sameSite = Strict。这似乎对我的问题有所帮助,在它仍然想挂起的情况下,我的 Timed re-direct 解决了这个问题。

对于那些也可能遇到这种奇怪情况的人,Cookie 修复的要点是...

  1. 更新您的 Owin 软件包以确保您使用的是 4.1 版
  2. 将 Startup.cs 中的 CookieAuthenticationOptions 调整为我在上面添加的项目以使 Owin cookie 兼容。
  3. 更新您的 Web.config 中的以下内容以使您的 Asp.net cookie 兼容

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

做这 3 件事(以及 运行 您在 SSL 下的项目)将导致 Chrome 将 cookie 报告为安全和严格。

Google 在没有 SameSite 属性的情况下对 how Chrome handles cookies 进行了更改。以前,Chrome 将未在 cookie 上设置 SameSite 属性视为与设置 SameSite=None 相同,这意味着浏览器将接受所有 cookie。现在,他们将其视为具有 SameSite=Lax,这将只接受来自同一域的 cookie。要获得与旧方法相同的效果,必须将属性设置为 SameSite=None; Secure.

我不知道这是否影响了您,但如果是这种情况,您会在 Chrome 控制台中看到错误。

正式版本是 2 月 4 日 IIRC,但他们正在分阶段推出以判断所引起的问题。

部分资源:
Microsoft ASP.NET blog about the upcoming changes / Archived copy
Chromium Blog / Archived Copy