Аутентификация форм ASP.NET продолжает отображать страницу входа на iPad - PullRequest
14 голосов
/ 07 июня 2011

У меня есть веб-приложение, которое отображает странное поведение при использовании с iPad. Иногда он продолжает отображать страницу входа, даже если пользователь проходит проверку подлинности, и я создаю файл cookie, который сохраняется на клиенте.

Приложение является приложением MVC2, и я вызываю метод контроллера через ajax для выполнения аутентификации. Если вызов ajax успешен, тогда клиент выполняет window.location.assign () для перехода пользователя на защищенную страницу (я делаю это для поддержки полноэкранного режима веб-приложения для iPad)

Я использую следующий код для создания куки:

string formsCookieStr = string.Empty;
FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(
            1,                              // version
            username,                       // user name
            DateTime.Now,                   // issue time
            DateTime.Now.AddMinutes(30),    // expires
            false,                          // Persistence
            userRoleData                    // user data
    );
formsCookieStr = FormsAuthentication.Encrypt(ticket);
HttpCookie FormsCookie = new HttpCookie(FormsAuthentication.FormsCookieName, formsCookieStr);
HttpContext.Response.Cookies.Add(FormsCookie);

URL-адрес для аутентификации - / Account / LogOn2. URL, который является «безопасной» страницей, - / Admin

Если я посмотрю журналы IIS (ниже), то увижу, что первый вызов / Account / LogOn2 передает правильное имя пользователя и пароль. Вторая запись журнала показывает GET, который впоследствии выполняет вызов ajax, и вы можете ясно видеть, что новый файл cookie ASPXAUTH сопровождает запрос - именно этот файл cookie был установлен после первого вызова. Почему тогда второй вызов приводит к 302 (перенаправление), когда запрос должным образом аутентифицирован, что подтверждается наличием файла cookie ASPXAUTH во втором вызове? Как будто сервер не «видит» куки-файл аутентификации и принудительно перенаправляет 302. Третья запись показывает перенаправление, в результате которого снова запрашивается форма для входа.

2011-06-07 16:33:37 W3SVC97442007 192.168.1.4 GET /Account/LogOn2 username=pete&password=wine&returnUrl=%2fProfileList 80 - 86.153.46.122 Mozilla/5.0+(iPad;+U;+CPU+OS+4_3_3+like+Mac+OS+X;+en-us)+AppleWebKit/533.17.9+(KHTML,+like+Gecko)+Mobile/8J3 .ASPXAUTH=214FCF8C485AD048B2A0833BCA77582097EBF8F88BC2B0A64D7CD4F2BD7B1D9CB0C4209DC82FFA93466A58462BCA7EAB0D35B8573CCC5AABDDD5F7ACD0D38FCCB7275A79606B990B8A189887F724BF4D30BF3F9474CCD872868FE6DB48A3825F8770116A1C142AAD99A195E5D46B7BD6DB8FCF709FDE79A6B4F70B99E9646B515946E82DD988231DCE8504E5B63134419A0A107CBB367ABC978BC71A5D7C2CEF;+ASP.NET_SessionId=5uu3m1db2iqgetgvmpjgnot2 200 0 0
2011-06-07 16:33:38 W3SVC97442007 192.168.1.4 GET /ProfileList - 80 - 86.153.46.122 Mozilla/5.0+(iPad;+U;+CPU+OS+4_3_3+like+Mac+OS+X;+en-us)+AppleWebKit/533.17.9+(KHTML,+like+Gecko)+Mobile/8J3 .ASPXAUTH=644A6CC55F3E1E78922FA2E5FF7E54CBF11654F636A58142C10BBD9CB8FAF440FC8A642AAE02A7A4AACC0904D27B225A38DA2016EB09AA03D761916048C35711C7AC136A9A58C63956DBCC3ABBED9EE5818F19E07585A93EB00950F53B5D3934650CFE611AAC926BC8D6BDBEE67F2EC8675ACBC66E594D0EF2556910A037E3C9782E134F56F7CAE9F9E31AD69CDB9F0C68B9B81BE7075918F9ECBC39DA03A77F;+ASP.NET_SessionId=5uu3m1db2iqgetgvmpjgnot2 302 0 0
2011-06-07 16:33:39 W3SVC97442007 192.168.1.4 GET /Account/LogOn ReturnUrl=%2fProfileList 80 - 86.153.46.122 Mozilla/5.0+(iPad;+U;+CPU+OS+4_3_3+like+Mac+OS+X;+en-us)+AppleWebKit/533.17.9+(KHTML,+like+Gecko)+Mobile/8J3 .ASPXAUTH=644A6CC55F3E1E78922FA2E5FF7E54CBF11654F636A58142C10BBD9CB8FAF440FC8A642AAE02A7A4AACC0904D27B225A38DA2016EB09AA03D761916048C35711C7AC136A9A58C63956DBCC3ABBED9EE5818F19E07585A93EB00950F53B5D3934650CFE611AAC926BC8D6BDBEE67F2EC8675ACBC66E594D0EF2556910A037E3C9782E134F56F7CAE9F9E31AD69CDB9F0C68B9B81BE7075918F9ECBC39DA03A77F;+ASP.NET_SessionId=5uu3m1db2iqgetgvmpjgnot2 200 0 0
2011-06-07 16:33:39 W3SVC97442007 192.168.1.4 POST /Sync/Users - 80 - 86.153.46.122 Mozilla/5.0+(iPad;+U;+CPU+OS+4_3_3+like+Mac+OS+X;+en-us)+AppleWebKit/533.17.9+(KHTML,+like+Gecko)+Mobile/8J3 .ASPXAUTH=644A6CC55F3E1E78922FA2E5FF7E54CBF11654F636A58142C10BBD9CB8FAF440FC8A642AAE02A7A4AACC0904D27B225A38DA2016EB09AA03D761916048C35711C7AC136A9A58C63956DBCC3ABBED9EE5818F19E07585A93EB00950F53B5D3934650CFE611AAC926BC8D6BDBEE67F2EC8675ACBC66E594D0EF2556910A037E3C9782E134F56F7CAE9F9E31AD69CDB9F0C68B9B81BE7075918F9ECBC39DA03A77F;+ASP.NET_SessionId=5uu3m1db2iqgetgvmpjgnot2 200 0 0
2011-06-07 16:33:39 W3SVC97442007 192.168.1.4 POST /Sync/Profiles - 80 - 86.153.46.122 Mozilla/5.0+(iPad;+U;+CPU+OS+4_3_3+like+Mac+OS+X;+en-us)+AppleWebKit/533.17.9+(KHTML,+like+Gecko)+Mobile/8J3 .ASPXAUTH=644A6CC55F3E1E78922FA2E5FF7E54CBF11654F636A58142C10BBD9CB8FAF440FC8A642AAE02A7A4AACC0904D27B225A38DA2016EB09AA03D761916048C35711C7AC136A9A58C63956DBCC3ABBED9EE5818F19E07585A93EB00950F53B5D3934650CFE611AAC926BC8D6BDBEE67F2EC8675ACBC66E594D0EF2556910A037E3C9782E134F56F7CAE9F9E31AD69CDB9F0C68B9B81BE7075918F9ECBC39DA03A77F;+ASP.NET_SessionId=5uu3m1db2iqgetgvmpjgnot2 200 0 0

Почему сервер не «видит» куки-файл аутентификации во втором запросе?

Большое спасибо за чтение этого места. Я тут рву свои волосы!

РЕДАКТИРОВАТЬ: подумал, что может быть полезно показать две записи журнала IIS, которые отражают успешную регистрацию:

2011-06-07 17:58:08 W3SVC97442007 192.168.1.4 GET /Account/LogOn2 username=pete&password=wine&returnUrl=%2fAdmin 80 - 86.153.46.122 Mozilla/5.0+(iPad;+U;+CPU+OS+4_3_3+like+Mac+OS+X;+en-us)+AppleWebKit/533.17.9+(KHTML,+like+Gecko)+Mobile/8J3 - 200 0 0
2011-06-07 17:58:09 W3SVC97442007 192.168.1.4 GET /Admin - 80 - 86.153.46.122 Mozilla/5.0+(iPad;+U;+CPU+OS+4_3_3+like+Mac+OS+X;+en-us)+AppleWebKit/533.17.9+(KHTML,+like+Gecko)+Mobile/8J3 .ASPXAUTH=4965435E85DA486CECFAC6234F7EB96E91608374522B842642C825328E12BB199809D4982BB55AA53BBDE7123679DD48D0518AF053EE6BC5AEBE653EA922BBBFB04CCCC7E369A2C42CDBF56F63DF184DE89D74F5632C3E6F007D8852177F37482A5E48A59B39DF9F8AC8271827ED15CFB70607E8960AAFFB12433C7D9391A15B1571740F888C5654AF5F52A50D2B9E1D21682A49C4DAA24686B19F888F92C255;+ASP.NET_SessionId=0q3ah5d1rkj5drkf0clrzwdi 200 0 0

Обратите внимание на код состояния HTTP 200 для второй записи.

РЕДАКТИРОВАТЬ Пример успешного входа в систему, затем загрузка на стороне клиента / ProfileList

2011-06-07 17:49:10 W3SVC97442007 192.168.1.4 GET /Account/LogOn2 username=pete&password=wine&returnUrl=%2fProfileList 80 - 86.153.46.122 Mozilla/5.0+(iPad;+U;+CPU+OS+4_3_3+like+Mac+OS+X;+en-us)+AppleWebKit/533.17.9+(KHTML,+like+Gecko)+Mobile/8J3 - 200 0 0
2011-06-07 17:49:13 W3SVC97442007 192.168.1.4 GET /ProfileList - 80 - 86.153.46.122 Mozilla/5.0+(iPad;+U;+CPU+OS+4_3_3+like+Mac+OS+X;+en-us)+AppleWebKit/533.17.9+(KHTML,+like+Gecko)+Mobile/8J3 .ASPXAUTH=26D4837E045282BF0F6118CABE52C0D1A264396BBDEE65E35502D77CD33AA39782B2F19D50971AD8C4F29BEF7DB268BF1F7359F1DBA58029C6BF1BFF6D95404B877F76D581FC8777F25030073CEB4D1ED5C591B532B41C212F772EC57717A50D063D4DAF195FCBFC4F2F6F88025043579E11D57030E6CFC51FB4250D8B3B99829E1446BD55B2C265A9153B23E2DC6D9419AA2E3E58AA01FC5760A5A7C44D69AE;+ASP.NET_SessionId=txvqo5pfod3bdg12d2llbh3g 200 0 0

Ответы [ 3 ]

17 голосов
/ 09 июня 2011

Я верю, что у меня есть ответ.Вам нужно специально установить web.config, чтобы принудительно использовать куки.Моя настройка аутентификации в web.config теперь выглядит следующим образом:

<authentication mode="Forms">
      <forms loginUrl="~/Account/LogOn" timeout="2880" 
             cookieless="UseCookies" 
             />
    </authentication>

Это запись cookieless = "UseCookies", которая решила проблему.Значением по умолчанию для этого является UseDeviceProfile.Должно быть, у iPad нет согласованного режима UseDeviceProfile.На iPad иногда это работало, иногда нет.Не спрашивай меня почему.Теперь кажется, что он работает последовательно.

0 голосов
/ 27 апреля 2014

Я потратил много часов на аналогичную проблему с IE11 на днях, и да, cookieless = "UseCookies", казалось, помогли с входом в систему ... но это не решило другую проблему ...

Оказалось, что проблема с IIS 7, НЕ распознающим IE11 как современный браузер и возвращающим его логику к базовой поддержке без файлов cookie, без поддержки javascript в браузере (IIS не будет отправлять файлы cookie или код javascript в браузер следовательно cookieless = "UseCookies" поможет решить проблему с cookie при входе в систему, но проблема с javascript все еще остается).

Решение, которое я нашел, заключалось в добавлении файлов определений .browser в папку App_Browsers моего приложения для FireFox и IE11, и мне больше не нужна опция cookieless = "UseCookies", по крайней мере для IE11

К сожалению, я не могу найти файлы .browser для iPad, и кажется, что у одного из моих клиентов точно такие же проблемы, как у вас с их iPad ... Возможно, кто-то еще нашел его и может поделиться им здесь? Если нет, я буду продолжать пытаться решить эту проблему и опубликую свое решение, как только найду его. До тех пор ... UseCookies должны делать.

0 голосов
/ 22 октября 2013

Просто чтобы добавить, я столкнулся с этой проблемой в IE11.Кажется, что любое приложение .net 4.0, использующее проверку подлинности с помощью форм, попадает в бесконечный цикл перенаправления, должно быть связано с пользовательским агентом.

Изменение конфигурации cookieless = "UseCookies" также устраняет проблему IE11

...