身份验证处理后，Chrome将不会重定向回到URL

Question

至少两年来，我一直在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的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="Strict" />
      <httpCookies requireSSL="true" />
   </system.web>
   

做这三件事（以及在SSL下运行项目）将导致Chrome将Cookie分别报告为“安全”和“严格”。

Answer 1

Google对how Chrome handles cookies进行了更改，没有使用src属性。以前，Chrome将未在Cookie上设置SameSite属性与设置SameSite相同，这意味着浏览器将接受所有cookie。现在，他们将其视为具有SameSite=None，它将仅接受来自同一域的cookie。为了获得与旧方法相同的效果，必须将属性设置为SameSite=Lax。

我无法确定这是否对您有影响，但是如果是这种情况，您会在Chrome控制台中看到错误。

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

一些资源：
Microsoft ASP.NET blog about the upcoming changes / Archived copy
Chromium Blog / Archived Copy