Браузер иногда теряет HttpCookie для аутентификации после обратной передачи и перенаправления - PullRequest
Новая
       28

Браузер иногда теряет HttpCookie для аутентификации после обратной передачи и перенаправления

4 голосов
/ 29 декабря 2010

В течение некоторого времени эта проблема была ноющей, но очень спорадической и ее трудно выделить.

Время от времени браузеры, прошедшие проверку подлинности в веб-приложении, были открыты некоторое время, входили и выходили из одного и того же веб-приложения несколько раз, имеют несколько вкладок, практически во всех браузерах (Chrome, IE , Firefox, Safari) и, по-видимому, наугад теряют способность сохранять AuthCookie после установки и последующего перенаправления. Закрытие браузера и начало нового сеанса решает проблему, равно как и открытие другого браузера и попытка аутентификации.

Наша команда использует аутентификацию по формам для всех наших веб-сайтов и веб-приложений. Это довольно типичная настройка, при которой отображается форма входа в систему, пользователь вводит учетные данные, и при событии щелчка обратной передачи устанавливается cookie-файл, затем происходит перенаправление на ту же страницу, где cookie-файл затем используется и используется для завершения аутентификации.

В этой ситуации 

FormsAuthentication.FormsCookieName = ".WebAuth"

Внутри события: 

    FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(1, Username, DateTime.Now, DateTime.Now.AddMinutes(SessionTimeout), false, Username);
    HttpCookie faCookie = new HttpCookie(FormsAuthentication.FormsCookieName, FormsAuthentication.Encrypt(authTicket));
    Response.Cookies.Add(faCookie);
Response.Redirect(Request.RawUrl, true);

После перенаправления в PreInit: 

HttpCookie authCookie = Request.Cookies[cookieName];

На данный момент переменная authCookie обычно не равна нулю, но в этих изолированных обстоятельствах, которые я описал выше, cookie возвращается в нуль после перенаправления.

Это происходит очень случайно, иногда за несколько недель до того, как это затрагивает одного из наших разработчиков. Как я уже сказал, перезапуск браузера решает проблему.

Сегодня у меня это происходило на нашем сервере разработки при использовании Chrome. Я вошел в приложение, разрешил приложению тайм-аут сеанса, а затем попытался снова войти в систему. При попытке входа в систему не удалось установить cookie. Я удаленно подключил Visual Studio к процессу на сервере, чтобы начать отладку. В течение всего времени я мог просматривать свой код, даже развертывать новые версии кода на сервере с обновлениями, перезапускать приложение, перезапускать IIS на сервере, подключать и повторно подключать к проекту, и проблема сохранялась в Chrome. В Firefox мне удалось пройти аутентификацию без проблем.

Из Chrome логин будет подтвержден, попытка установить ответный cookie, как описано выше. До перенаправления я мог видеть правильно настроенный Cookie-файл ответа, а также его аналог в Cookie-запросах. Однако при каждом перенаправлении после, казалось бы, успешного входа в систему файл cookie ответа и запроса исчезает.

Я включил Trace в приложении для просмотра коллекции файлов cookie:

. В коллекции файлов cookie запроса есть .WebAuth, а также ASP.NET_SessionId и несколько ASPSESSIONIDxxxxxxxx, но при загрузке страницы в области Request.Cookies доступны только файлы cookie ASP.NET_SessionId и ASPSESSIONIDxxxxxxxx, без признаков .WebAuth. Однако в информации о трассировке страницы после рендеринга указано несколько файлов cookie .WebAuth, просто кажется, что страница не имеет к ним доступа.

В первую очередь, в рабочей версии после аутентификации в информации о трассировке страницы присутствуют как ответ .WebAuth, так и запрос файла cookie. Но в неработающем окне браузера cookie-файл ответа отсутствует.

Кто-нибудь еще имел опыт с этим? Это такая ноющая проблема, и такая спорадическая, но я бы хотел ее решить. Я обеспокоен тем, что это может повлиять на пользователей, и мы не будем знать, так как описание проблемы настолько запутанно.

Ответы [ 3 ]

1 голос
/ 01 мая 2015

Это непостоянная проблема с файлами cookie. Время сеанса просто истекло.

Попробуйте изменить false на true в этой строке: 

FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(1, Username, DateTime.Now, DateTime.Now.AddMinutes(SessionTimeout), true, Username);

Также добавьте 

faCookie.Expires = DateTime.Now.AddMinutes(SessionTimeout);
1 голос
/ 08 января 2011

В зависимости от вашего сценария вы можете столкнуться с ограничениями браузера на количество файлов cookie на домен / всего.Ограничения относительно высоки, но существуют (спецификация: http://www.ietf.org/rfc/rfc2109.txt,, раздел 6.3, некоторая свежая информация - http://www.nczonline.net/blog/2008/05/17/browser-cookie-restrictions/)

. Если это произойдет снова, попробуйте посмотреть на реальные ответы сервера (например, с помощью Fiddler), чтобы увидеть, отправляются ли куки в браузер. Проверьте, какие куки установлены для домена и текущей страницы (в зависимости от браузера, есть разные способы сделать это, во всех браузерах вы можете увидеть некоторые куки, выполнив следующие действия в адресной строке javascript :alert(document.cookie))

0 голосов
/ 01 апреля 2016

Я попал в подобную ситуацию, все было точно так, как вы описали.Но позже причина была найдена.

ASP.NET и IIS воспринимали MyApplication и myapplication как одно равное, но браузеры воспринимали их как разные.Таким образом, когда мы устанавливаем куки авторизации для / MyApplication, они не отправляются на сервер, когда мы переходим к /myapplication.

Исправление следующее: 

    protected void Application_BeginRequest(object sender, EventArgs e)
    {
        string url = HttpContext.Current.Request.Url.PathAndQuery;
        string application = HttpContext.Current.Request.ApplicationPath;

        if (!url.StartsWith(application))
        {
            HttpContext.Current.Response.Redirect(application + url.Substring(application.Length));
            Response.End();
            return;
        }
    }
...