ASP.NET_SessionId + OWIN Cookies не отправляются в браузер
У меня странная проблема с использованием аутентификации файла cookie Оуэна.
Когда я запускаю свой сервер IIS, аутентификация отлично работает в IE/Firefox и Chrome.
Я начал проводить тестирование с аутентификацией и входом в систему на разных платформах, и у меня возникла странная ошибка. Спорадически среда Owin / IIS просто не отправляет куки в браузеры. Я введу имя пользователя и пароль, которые верны, код запускается, но в браузер не доставляются файлы 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);
}
}
}
});
И в моей процедуре входа в систему у меня есть следующий код:
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) При входе в систему я получаю ASP.NET_SessionId + мой файл cookie для аутентификации. 2) Я захожу на страницу, которая устанавливает session.contents... 3) Откройте новый браузер (Firefox) и попробуйте войти в систему, и он не получит ASP.NET_SessionId и не получит файл cookie для аутентификации. имеет ASP.NET_SessionId, он продолжает работать. В тот момент, когда я удаляю этот файл cookie, возникает та же проблема, что и во всех других браузерах, с которыми я работаю по ip-адресу (10.xxx) и localhost.
Обновление 2: принудительное создание ASPNET_SessionId сначала на моей странице login_load перед аутентификацией с OWIN.
1) прежде чем пройти аутентификацию с OWIN, я делаю случайный выбор Session.Content значение на моей странице входа в систему, чтобы запустить ASP.NET_SessionId
2) затем я аутентифицируюсь и делаю дальнейшие сеансы 3) Кажется, теперь работают другие браузеры
Это странно. Я могу только заключить, что это как-то связано с ASP и OWIN, думая, что они находятся в разных доменах или что-то в этом роде.
Обновление 3 - Странное поведение между ними.
Выявлено дополнительное странное поведение - Таймаут Оуэна и ASP-сессии различны. Что я вижу, так это то, что мои сеансы Owin остаются живыми дольше, чем мои сеансы ASP через некоторый механизм. Поэтому при входе в систему: 1.) У меня есть сеанс аутентификации, основанный на кулинарии 2.) Я установил несколько переменных сеанса
Мои переменные сеанса (2) "умирают" до того, как переменная сеанса файла cookie owin вызывает повторный вход в систему, что вызывает неожиданное поведение во всем приложении. (Человек вошел в систему, но на самом деле не вошел в систему)
Обновление 3B
После некоторых копаний я увидел на странице несколько комментариев, в которых говорится, что время аутентификации "форм" и время сеанса должны совпадать. Я думаю, что обычно они синхронизированы, но по какой-то причине они не синхронизированы.
Резюме обходных путей
1) Всегда создавайте сеанс перед аутентификацией. В основном создать сеанс при запуске приложения Session["Workaround"] = 0;
2) [Экспериментально], если вы сохраняете куки, убедитесь, что ваш OWIN timeout / length больше, чем ваш sessionTimeout в вашем web.config (в тестировании)
8 ответов
Я столкнулся с той же проблемой и проследил причину реализации хостинга OWIN ASP.NET. Я бы сказал, что это ошибка.
Некоторый фон
Мои выводы основаны на следующих версиях сборки:
- Microsoft.Owin, версия =2.0.2.0, культура = нейтральная, PublicKeyToken = 31bf3856ad364e35
- Microsoft.Owin.Host.SystemWeb, версия =2.0.2.0, культура = нейтральная, PublicKeyToken = 31bf3856ad364e35
- System.Web, версия =4.0.0.0, культура = нейтральная, PublicKeyToken = b03f5f7f11d50a3a
OWIN использует собственную абстракцию для работы с ответными файлами cookie (Microsoft.Owin.ResponseCookieCollection). Эта реализация напрямую переносит коллекцию заголовков ответов и соответственно обновляет заголовок Set-Cookie. OWIN ASP.NET host (Microsoft.Owin.Host.SystemWeb) просто оборачивает System.Web.HttpResponse и его коллекцию заголовков. Поэтому, когда новый файл cookie создается через OWIN, ответный заголовок Set-Cookie изменяется напрямую.
Но ASP.NET также использует свою собственную абстракцию для работы с куки-файлами ответа. Это предоставляется нам как свойство System.Web.HttpResponse.Cookies и реализуется закрытым классом System.Web.HttpCookieCollection. Эта реализация не переносит ответный заголовок Set-Cookie напрямую, но использует некоторые оптимизации и несколько внутренних уведомлений, чтобы продемонстрировать, что его измененное состояние передано объекту ответа.
Затем в конце времени существования запроса наступает момент, когдапроверяется измененное состояние HttpCookieCollection (System.Web.HttpResponse.GenerateResponseHeadersForCookies()) и файлы cookie сериализуются в заголовок Set-Cookie. Если эта коллекция находится в каком-то определенном состоянии, весь заголовок Set-Cookie сначала очищается и воссоздается из файлов cookie, хранящихся в коллекции.
Реализация сеанса ASP.NET использует свойствоSystem.Web.HttpResponse.Cookies для хранения файла cookie ASP.NET_SessionId. Также есть некоторая базовая оптимизация в модуле состояния сеанса ASP.NET (System.Web.SessionState.SessionStateModule), реализованная с помощью статического свойства s_sessionEverSet, которое само собой понятно. Если вы когда-нибудь сохраните что-либо для состояния сеанса в своем приложении, этот модуль будет выполнять немного больше работы для каждого запроса.
Вернуться к нашей проблеме входа
Со всеми этими частями ваши сценарии могут быть объяснены.
Случай 1 - Сессия никогда не была установлена
System.Web.SessionState.SessionStateModule, свойство s_sessionEverSet имеет значение false. Идентификаторы сеанса не генерируются модулем состояния сеанса, и состояние коллекцииSystem.Web.HttpResponse.Cookiesне определяется как измененное. В этом случае OWIN куки отправляются в браузер корректно и логин работает.
Случай 2 - Сессия использовалась где-то в приложении, но не раньше, чем пользователь пытается аутентифицироваться
System.Web.SessionState.SessionStateModule, свойство s_sessionEverSet имеет значение true. Идентификаторы сеанса генерируются с помощью SessionStateModule, ASP.NET_SessionId добавляется в коллекцию System.Web.HttpResponse.Cookies, но он удаляется позднее при жизни запроса, поскольку сеанс пользователя фактически пуст. В этом случае состояние коллекции System.Web.HttpResponse.Cookies определяется как измененное, и заголовокSet-Cookie сначала очищается перед сериализацией файлов cookie в значение заголовка.
В этом случае cookie-файлы ответа OWIN "теряются", и пользователь не проходит проверку подлинности и перенаправляется обратно на страницу входа.
Случай 3 - Сеанс используется до того, как пользователь пытается аутентифицироваться
System.Web.SessionState.SessionStateModule, свойство s_sessionEverSet имеет значение true. Идентификаторы сеанса генерируются SessionStateModule, ASP.NET_SessionId добавляется в System.Web.HttpResponse.Cookies. Из-за внутренней оптимизации в System.Web.HttpCookieCollection и System.Web.HttpResponse.GenerateResponseHeadersForCookies() заголовок Set-Cookie НЕ сначала очищается, а только обновляется.
В этом случае в ответ отправляются как файлы cookie аутентификации OWIN, так и файл cookie ASP.NET_SessionId, и вход в систему работает.
Более общая проблема с куки
Как видите, проблема носит более общий характер и не ограничивается сессией ASP.NET. Если вы размещаете OWIN через Microsoft.Owin.Host.SystemWeb и вы / что-то напрямую используете коллекцию System.Web.HttpResponse.Cookies, вы рискуете.
Например, это работает, и оба куки правильно отправляются в браузер...
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();
}
Оба протестированы из VS2013, IISExpress и шаблон проекта MVC по умолчанию.
Короче говоря, менеджер файлов cookie .NET превзойдет менеджер файлов cookie OWIN и перезапишет файлы cookie, установленные на слое OWIN. Исправление заключается в использовании класса SystemWebCookieManager, предоставленного в качестве решения для проекта Katana здесь. Вам нужно использовать этот класс или аналогичный ему, что заставит OWIN использовать менеджер файлов cookie .NET, чтобы не было несоответствий:
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),
});
}
}
При запуске приложения просто назначьте его при создании зависимостей OWIN:
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
...
CookieManager = new SystemWebCookieManager()
...
});
Подобный ответ был предоставлен здесь, но он не включает всю кодовую базу, необходимую для решения проблемы, поэтому я вижу необходимость добавить его здесь, потому что внешняя ссылка на проект Katana может быть недоступна, и это должно быть полностью записано как решение здесь также.
Начав с великолепного анализа @TomasDolezal, я взглянул на источник Owin и System.Web.
Проблема в том, что System.Web имеет свой собственный основной источник информации о файлах cookie, а это не заголовок Set-Cookie. Овин знает только о заголовке Set-Cookie. Обходной путь должен убедиться, что любые куки, установленные Оуэном, также установлены в HttpContext.Current.Response.Cookies коллекция.
Я сделал небольшое промежуточное программное обеспечение ( источник, nuget), которое делает именно это, и предназначено для размещения непосредственно над регистрацией промежуточного программного обеспечения cookie.
app.UseKentorOwinCookieSaver();
app.UseCookieAuthentication(new CookieAuthenticationOptions());
Команда Katana ответила на вопрос, поднятый Томасом Долезаром, и разместила документацию об обходных путях:
Обходные пути делятся на две категории. Одним из них является переконфигурирование System.Web, чтобы избежать использования коллекции Response.Cookies и перезаписи файлов cookie OWIN. Другой подход заключается в повторной настройке затронутых компонентов OWIN, чтобы они записывали файлы cookie непосредственно в коллекцию Response.Cookies System.Web.
- Убедитесь, что сеанс установлен до проверки подлинности. Конфликт между файлами cookie System.Web и Katana происходит по запросу, поэтому приложение может установить сеанс по какому-либо запросу до процесса проверки подлинности. Это должно быть легко сделать, когда пользователь впервые прибывает, но это может быть труднее гарантировать позже, когда сессия или файлы cookie авторизации истекают и / или должны быть обновлены.
- Отключите SessionStateModule - если приложение не полагается на информацию о сеансе, но модуль сеанса все еще устанавливает файл cookie, который вызывает вышеуказанный конфликт, то вы можете отключить модуль состояния сеанса.
- Переконфигурируйте CookieAuthenticationMiddleware для прямой записи в коллекцию cookie System.Web.
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
// ...
CookieManager = new SystemWebCookieManager()
});
См. Реализацию SystemWebCookieManager из документации (ссылка выше)
Больше информации здесь
редактировать
Ниже приведены шаги, которые мы предприняли для решения проблемы. И 1., и 2. решили проблему также отдельно, но мы решили применить оба на всякий случай:
1. Используйте SystemWebCookieManager
2. Установите переменную сеанса:
protected override void Initialize(RequestContext requestContext)
{
base.Initialize(requestContext);
// See http://stackru.com/questions/20737578/asp-net-sessionid-owin-cookies-do-not-send-to-browser/
requestContext.HttpContext.Session["FixEternalRedirectLoop"] = 1;
}
(примечание: метод Initialize, описанный выше, является логическим местом для исправления, поскольку base.Initialize делает Session доступным. Однако исправление также можно применить позже, поскольку в OpenId сначала выполняется анонимный запрос, затем перенаправляется к поставщику OpenId, а затем возвращается к приложению. Проблемы будут возникать после перенаправления обратно в приложение, в то время как исправление устанавливает переменную сеанса уже во время первого анонимного запроса, таким образом устраняя проблему до того, как произойдет какое-либо перенаправление)
Редактировать 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),
});
}
}
Ответы уже были предоставлены, но в owin 3.1.0 есть класс SystemWebChunkingCookieManager, который можно использовать.
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
...
CookieManager = new SystemWebChunkingCookieManager()
...
});
Я столкнулся с аналогичной проблемой с Visual Studio 2017 и .net MVC 5.2.4, обновление Nuget Microsoft.Owin.Security.Google до последней версии, которая в настоящее время 4.0.1, работала для меня! Надеюсь, это кому-то поможет!
Если вы сами устанавливаете куки в промежуточном программном обеспечении OWIN, тогда 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");
}
Самое быстрое однострочное кодовое решение:
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);
У меня был тот же симптом, что заголовок Set-Cookie не отправлялся, но ни один из этих ответов не помог мне. Все работало на моем локальном компьютере, но при развертывании в производство заголовки set-cookie никогда не устанавливались.
Оказывается, это была комбинация использования пользовательских CookieAuthenticationMiddleware с WebApi вместе с поддержкой сжатия WebApi
К счастью, я использовал ELMAH в своем проекте, что позволило мне войти в это исключение:
Сервер System.Web.HttpException не может добавить заголовок после отправки заголовков HTTP.
Что привело меня к этой проблеме GitHub
По сути, если у вас странная настройка, как у меня, вы захотите отключить сжатие для ваших контроллеров / методов WebApi, которые устанавливают куки, или попробуйте OwinServerCompressionHandler,