ASP.NET_SessionId + OWIN Cookies不发送给浏览器

我使用Owin cookie身份validation有一个奇怪的问题。

当我启动我的IIS服务器身份validation在IE / Firefox和Chrome浏览器上工作得很好。

我开始做一些testing与authentication和login在不同的平台上,我想出了一个奇怪的错误。 Owin框架/ IIS偶尔不会向浏览器发送任何cookie。 我将input用户名和密码,这是正确的代码运行,但没有cookie传递到浏览器根本。 如果我重新启动服务器,它开始工作,然后在某个时候,我会尝试login,再次的cookie停止交付。 单步执行代码并不会导致错误。

app.UseCookieAuthentication(new CookieAuthenticationOptions { AuthenticationMode = AuthenticationMode.Active, CookieHttpOnly = true, AuthenticationType = "ABC", LoginPath = new PathString("/Account/Login"), CookiePath = "/", CookieName = "ABC", Provider = new CookieAuthenticationProvider { OnApplyRedirect = ctx => { if (!IsAjaxRequest(ctx.Request)) { ctx.Response.Redirect(ctx.RedirectUri); } } } }); 

在我的login过程中,我有以下代码:

 IAuthenticationManager authenticationManager = HttpContext.Current.GetOwinContext().Authentication; authenticationManager.SignOut(DefaultAuthenticationTypes.ExternalCookie); var authentication = HttpContext.Current.GetOwinContext().Authentication; var identity = new ClaimsIdentity("ABC"); identity.AddClaim(new Claim(ClaimTypes.Name, user.Username)); identity.AddClaim(new Claim(ClaimTypes.NameIdentifier, user.User_ID.ToString())); identity.AddClaim(new Claim(ClaimTypes.Role, role.myRole.ToString())); authentication.AuthenticationResponseGrant = new AuthenticationResponseGrant(identity, new AuthenticationProperties() { IsPersistent = isPersistent }); authenticationManager.SignIn(new AuthenticationProperties() {IsPersistent = isPersistent}, identity); 

更新1:似乎是问题的一个原因是当我添加项目会话的问题开始。 像Session.Content["ABC"]= 123添加一些简单的东西似乎造成了这个问题。

我可以做出如下:1)(Chrome)当我login时,我得到了ASP.NET_SessionId +我的身份validationcookie。 2)我去一个页面,设置一个session.contents … 3)打开一个新的浏览器(Firefox),并尝试login,它不会收到一个ASP.NET_SessionId也没有得到一个身份validationCookie 4)虽然第一个浏览器有ASP.NET_SessionId它继续工作。 当我删除这个cookie时,它和我在ip address(10.xxx)和localhost上工作的所有其他浏览器都有同样的问题。

更新2:在使用OWIN进行身份validation之前,首先在我的login_load页面上强制创buildASPNET_SessionId。

1)在使用OWIN进行身份validation之前,我在login页面上创build一个随机的Session.Content值来启动ASP.NET_SessionId 2)然后我进行身份validation并进行更多的会话3)其他浏览器似乎可以正常工作

这是奇怪的。 我只能得出这样的结论,这与ASP和OWIN有关,因为他们在不同的领域或类似的东西。

更新3 – 两者之间的奇怪行为。

其他奇怪的行为 – Owin和ASP会话超时是不同的。 我所看到的是,我的欧文会议通过某种机制比我的ASP会议活得更久。 所以login时:1)我有一个基于烹饪的auth会话2)我设置了几个会话variables

我的会话variables(2)在owin cookie会话variables强制重新login之前“死掉”,这会在整个应用程序中导致意外的行为。 (人login但没有真正login)

更新3B

经过一番挖掘,我看到一些页面上的评论,说“表单”身份validation超时和会话超时需要匹配。 我通常认为两者是同步的,但无论出于何种原因,两者不同步。

变通办法摘要

1)在authentication之前总是先创build一个Session。 基本上创build会话,当你启动应用程序Session["Workaround"] = 0;

2)[实验]如果你坚持Cookie,请确保你的OWIN超时/长度比你的web.config中的sessionTimeout长(在testing中)

我遇到了同样的问题,并追溯到OWIN ASP.NET托pipe实施的原因。 我会说这是一个错误。

一些背景

我的发现是基于这些汇编版本:

  • Microsoft.Owin,Version = 2.0.2.0,Culture = neutral,PublicKeyToken = 31bf3856ad364e35
  • Microsoft.Owin.Host.SystemWeb,Version = 2.0.2.0,Culture = neutral,PublicKeyToken = 31bf3856ad364e35
  • System.Web,Version = 4.0.0.0,Culture = neutral,PublicKeyToken = b03f5f7f11d50a3a

OWIN使用它自己的抽象来处理Cookies( Microsoft.Owin.ResponseCookieCollection )。 这个实现直接包装响应头集合并相应地更新Set-Cookie头。 OWIN ASP.NET主机( Microsoft.Owin.Host.SystemWeb )只是包装System.Web.HttpResponse和它的头集合。 所以当通过OWIN创build新的cookie时,直接改变响应Set-Cookie头。

但是ASP.NET也使用它自己的抽象来处理Cookies响应。 这是作为System.Web.HttpResponse.Cookies属性暴露给我们,并通过密封类System.Web.HttpCookieCollection实现 。 此实现不直接包装响应Set-Cookie头,但使用一些优化和less量的内部通知来将其状态更改为响应对象。

然后在请求生命期的最后阶段,testing了HttpCookieCollection更改状态( System.Web.HttpResponse.GenerateResponseHeadersForCookies() ),并将cookie序列化为Set-Cookie标头。 如果此集合处于某种特定状态,则整个Set-Cookie标头首先被清除并从存储在集合中的cookie中重新创build。

ASP.NET会话实现使用System.Web.HttpResponse.Cookies属性来存储它的ASP.NET_SessionId cookie。 在ASP.NET会话状态模块( System.Web.SessionState.SessionStateModule )中还有一些基本的优化,通过名为s_sessionEverSet的静态属性来实现,这是非常自我解释的。 如果您在应用程序中将会话状态存储为会话状态,则该模块将为每个请求做更多的工作。


回到我们的login问题

所有这些作品都可以解释你的场景。

案例1 – 会议从未设置

System.Web.SessionState.SessionStateModule ,s_sessionEverSet属性为false。 会话状态模块和System.Web.HttpResponse没有生成会话标识.Cookie收集状态不会被检测为已更改 。 在这种情况下,OWIN cookies被正确地发送到浏览器并且login工作。

情况2 – 会话在应用程序的某个地方使用,但在用户尝试进行身份validation之前没有使用

System.Web.SessionState.SessionStateModule ,s_sessionEverSet属性为true。 会话Id由SessionStateModule生成,ASP.NET_SessionId被添加到System.Web.HttpResponse.Cookies集合中,但稍后在请求生命期中被删除,因为用户的会话事实上是空的。 在这种情况下, System.Web.HttpResponse.Cookies集合状态会被检测为已更改,并且会在Cookie被序列化为标头值之前首先清除Set-Cookie标头。

在这种情况下,OWIN响应cookie将“丢失”,用户未被authentication,并被redirect回login页面。

情况3 – 会话在用户尝试authentication之前使用

System.Web.SessionState.SessionStateModule ,s_sessionEverSet属性为true。 会话Id由SessionStateModule生成,ASP.NET_SessionId被添加到System.Web.HttpResponse.Cookies 。 由于System.Web.HttpCookieCollectionSystem.Web.HttpResponse.GenerateResponseHeadersForCookies()中的内部优化, Set-Cookie头不是首先被清除,而是只被更新。

在这种情况下,OWINauthenticationcookie和ASP.NET_SessionId cookie都会作为响应发送并login。


Cookie更一般的问题

正如你所看到的问题是更一般的,不限于ASP.NET会话。 如果您通过Microsoft.Owin.Host.SystemWeb托pipeOWIN,并且您正在直接使用System.Web.HttpResponse.Cookies集合,那么您将面临风险。

例如这个工程 ,两个cookie都被正确地发送到浏览器…

 public ActionResult Index() { HttpContext.GetOwinContext() .Response.Cookies.Append("OwinCookie", "SomeValue"); HttpContext.Response.Cookies["ASPCookie"].Value = "SomeValue"; return View(); } 

但是, 这不 ,OwinCookie是“失去”…

 public ActionResult Index() { HttpContext.GetOwinContext() .Response.Cookies.Append("OwinCookie", "SomeValue"); HttpContext.Response.Cookies["ASPCookie"].Value = "SomeValue"; HttpContext.Response.Cookies.Remove("ASPCookie"); return View(); } 

两个testing从VS2013,IISExpress和默认的MVC项目模板。

从@TomasDolezal的伟大分析开始,我看了Owin和System.Web源代码。

问题是System.Web有自己的Cookie信息的主要来源,而不是Set-Cookie头。 Owin只知道Set-Cookie头。 解决方法是确保由Owin设置的任何cookie也设置在HttpContext.Current.Response.Cookies集合中。

我制作了一个小的中间件( 源代码 , nuget ),这个中间件就是要放在cookie中间件注册的上方。

 app.UseKentorOwinCookieSaver(); app.UseCookieAuthentication(new CookieAuthenticationOptions()); 

简而言之, .NET cookiepipe理器将赢得OWIN cookiepipe理器并覆盖OWIN层上设置的cookie 。 解决方法是使用SystemWebCookieManager类,作为Katana项目的解决scheme提供 。 您需要使用此类或类似的类,这将强制OWIN使用.NET Cookiepipe理器,因此不存在任何不一致之处

 public class SystemWebCookieManager : ICookieManager { public string GetRequestCookie(IOwinContext context, string key) { if (context == null) { throw new ArgumentNullException("context"); } var webContext = context.Get<HttpContextBase>(typeof(HttpContextBase).FullName); var cookie = webContext.Request.Cookies[key]; return cookie == null ? null : cookie.Value; } public void AppendResponseCookie(IOwinContext context, string key, string value, CookieOptions options) { if (context == null) { throw new ArgumentNullException("context"); } if (options == null) { throw new ArgumentNullException("options"); } var webContext = context.Get<HttpContextBase>(typeof(HttpContextBase).FullName); bool domainHasValue = !string.IsNullOrEmpty(options.Domain); bool pathHasValue = !string.IsNullOrEmpty(options.Path); bool expiresHasValue = options.Expires.HasValue; var cookie = new HttpCookie(key, value); if (domainHasValue) { cookie.Domain = options.Domain; } if (pathHasValue) { cookie.Path = options.Path; } if (expiresHasValue) { cookie.Expires = options.Expires.Value; } if (options.Secure) { cookie.Secure = true; } if (options.HttpOnly) { cookie.HttpOnly = true; } webContext.Response.AppendCookie(cookie); } public void DeleteCookie(IOwinContext context, string key, CookieOptions options) { if (context == null) { throw new ArgumentNullException("context"); } if (options == null) { throw new ArgumentNullException("options"); } AppendResponseCookie( context, key, string.Empty, new CookieOptions { Path = options.Path, Domain = options.Domain, Expires = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc), }); } } 

在您的应用程序启动时,只需在创buildOWIN依赖项时指派它:

 app.UseCookieAuthentication(new CookieAuthenticationOptions { ... CookieManager = new SystemWebCookieManager() ... }); 

在这里也提供了类似的答案,但是它并不包含解决问题所需的全部代码库,所以我觉得有必要在这里添加它,因为Katana项目的外部链接可能会下降,这应该是完全logging的作为这里的解决scheme。

武士刀团队回答Tomas Dolezar提出的问题 ,并发布有关解决方法的文档 :

变通办法分为两类。 一个是重新configurationSystem.Web,以避免使用Response.Cookies集合并覆盖OWIN cookie。 另一种方法是重新configuration受影响的OWIN组件,以便直接将Cookie写入System.Web的Response.Cookies集合。

  • 确保会话在authentication之前build立:System.Web和Katana cookie之间的冲突是每个请求的,所以应用程序可能在authenticationstream程之前在某个请求上build立会话。 当用户第一次到达时,这应该很容易,但是当会话或授权cookie过期和/或需要刷新时可能更难保证。
  • 禁用SessionStateModule – 如果应用程序不依赖会话信息,但会话模块仍然设置导致上述冲突的Cookie,则可以考虑禁用会话状态模块。
  • 重新configurationCookieAuthenticationMiddleware直接写入System.Web的cookie集合。
 app.UseCookieAuthentication(new CookieAuthenticationOptions { // ... CookieManager = new SystemWebCookieManager() }); 

请参阅文档中的SystemWebCookieManager实现(上面的链接)

更多信息在这里

编辑

下面我们解决问题的步骤。 1.和2.都分别解决了这个问题,但是我们决定应用两者以防万一:

1.使用SystemWebCookieManager

2.设置会话variables:

 protected override void Initialize(RequestContext requestContext) { base.Initialize(requestContext); // See http://stackoverflow.com/questions/20737578/asp-net-sessionid-owin-cookies-do-not-send-to-browser/ requestContext.HttpContext.Session["FixEternalRedirectLoop"] = 1; } 

(注意:上面的Initialize方法是修复的合理位置,因为base.Initialize使得Session可用,但是修补程序也可以稍后使用,因为在OpenId中首先有一个匿名请求,然后redirect到OpenId提供程序,然后返回在redirect回应用程序之后会发生问题,而修复程序在第一次匿名请求期间已经设置了会话variables,从而在任何redirect返回之前修复问题)

编辑2

从Katana项目复制粘贴2016-05-14:

加这个:

 app.UseCookieAuthentication(new CookieAuthenticationOptions { // ... CookieManager = new SystemWebCookieManager() }); 

…和这个:

 public class SystemWebCookieManager : ICookieManager { public string GetRequestCookie(IOwinContext context, string key) { if (context == null) { throw new ArgumentNullException("context"); } var webContext = context.Get<HttpContextBase>(typeof(HttpContextBase).FullName); var cookie = webContext.Request.Cookies[key]; return cookie == null ? null : cookie.Value; } public void AppendResponseCookie(IOwinContext context, string key, string value, CookieOptions options) { if (context == null) { throw new ArgumentNullException("context"); } if (options == null) { throw new ArgumentNullException("options"); } var webContext = context.Get<HttpContextBase>(typeof(HttpContextBase).FullName); bool domainHasValue = !string.IsNullOrEmpty(options.Domain); bool pathHasValue = !string.IsNullOrEmpty(options.Path); bool expiresHasValue = options.Expires.HasValue; var cookie = new HttpCookie(key, value); if (domainHasValue) { cookie.Domain = options.Domain; } if (pathHasValue) { cookie.Path = options.Path; } if (expiresHasValue) { cookie.Expires = options.Expires.Value; } if (options.Secure) { cookie.Secure = true; } if (options.HttpOnly) { cookie.HttpOnly = true; } webContext.Response.AppendCookie(cookie); } public void DeleteCookie(IOwinContext context, string key, CookieOptions options) { if (context == null) { throw new ArgumentNullException("context"); } if (options == null) { throw new ArgumentNullException("options"); } AppendResponseCookie( context, key, string.Empty, new CookieOptions { Path = options.Path, Domain = options.Domain, Expires = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc), }); } } 

最快的单行代码解决scheme:

 HttpContext.Current.Session["RunSession"] = "1"; 

只需在CreateIdentity方法之前添加这一行:

 HttpContext.Current.Session["RunSession"] = "1"; var userIdentity = userManager.CreateIdentity(user, DefaultAuthenticationTypes.ApplicationCookie); _authenticationManager.SignIn(new AuthenticationProperties { IsPersistent = rememberLogin }, userIdentity); 

如果你自己在OWIN中间件中设置cookie,那么使用OnSendingHeaders似乎可以解决这个问题。

例如,使用下面的代码owinResponseCookie2将被设置,即使owinResponseCookie1不是:

 private void SetCookies() { var owinContext = HttpContext.GetOwinContext(); var owinResponse = owinContext.Response; owinResponse.Cookies.Append("owinResponseCookie1", "value1"); owinResponse.OnSendingHeaders(state => { owinResponse.Cookies.Append("owinResponseCookie2", "value2"); }, null); var httpResponse = HttpContext.Response; httpResponse.Cookies.Remove("httpResponseCookie1"); } 

我有同样的Set-Cookie头没有被发送的症状,但这些答案都没有帮助我。 一切工作在我的本地机器,但部署到生产时,set-cookie头永远不会被设置。

事实certificate,这是一个使用CookieAuthenticationMiddleware自定义CookieAuthenticationMiddleware和WebApi压缩支持

幸运的是我在我的项目中使用ELMAH,这让我logging下这个exception:

System.Web.HttpException在发送HTTP头之后,服务器无法追加头。

这导致了我的这个GitHub问题

基本上,如果你有一个奇怪的设置像我一样,你会想禁用压缩设置cookie的WebApi控制器/方法,或者尝试OwinServerCompressionHandler