ASP.NET表单身份验证在iPad上持续显示登录页面

我有一个web应用程序，当从iPad上使用时，它显示出奇怪的行为。有时，它会一直显示登录页面，即使用户通过了身份验证，我创建了一个存储在客户机上的cookie

该应用程序是一个MVC2应用程序，我通过ajax调用一个控制器方法来执行身份验证。如果ajax调用成功，那么客户端将执行window.location.assign（）将用户导航到安全页面。（我这样做是为了支持全屏iPad web app模式）

我使用以下代码创建cookie：

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的第一次调用传递了正确的用户名和密码。 第二个日志条目显示了ajax调用随后进行的GET，您可以清楚地看到，请求附带了一个新的ASPXAUTH cookie——这是在第一次调用之后设置的cookie。 那么，当请求经过正确的身份验证时，为什么第二次调用会导致302（重定向），第二次调用中存在ASPXAUTH cookie就证明了这一点？这就好像服务器没有“看到”身份验证cookie，而是在强制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

为什么服务器在第二个请求中没有“看到”身份验证cookie

非常感谢你读到这里。我要把我的头发扯出来了

编辑：认为显示反映成功登录的两个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

---

我相信我有答案。您需要专门设置web.config以强制使用Cookie。web.config中的身份验证设置现在如下所示：

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

---

是cookieless=“UseCookies”条目解决了问题。此文件的默认值为UseDeviceProfile。一定是iPad没有一个一致的UseDeviceProfile机制。在iPad上，它有时工作，有时不工作。别问我为什么。现在它似乎一直在工作。

只是补充一下，我在IE11中遇到了这个问题。任何使用表单身份验证的.NET4.0应用程序似乎都会进入无限重定向循环，这一定与用户代理有关

---

cookieless=“UseCookies”配置更改还修复了IE11的问题。前几天，我花了很多时间研究IE11的类似问题，是的，cookieless=“UseCookies”似乎对登录有所帮助。。。但它并没有解决另一个问题

IIS 7没有将IE11识别为现代浏览器，并将其逻辑恢复为基本支持，浏览器中没有cookie，没有javascript支持，这是一个问题（IIS不会向浏览器发送cookie或javascript代码，因此cookieless=“UseCookies”将有助于解决登录时的cookie问题，但javascript仍然是一个问题）

我找到的一个解决方案是将.browser定义文件添加到FireFox和IE11应用程序的app_Browsers文件夹中，我不再需要cookieless=“UseCookies”选项，至少对于IE11是这样

---

不幸的是，我找不到任何适用于iPad的.browser文件，而且我的一个客户的iPad出现了与您的完全相同的问题。。。也许有人发现了它，可以在这里分享？如果没有，我会继续尝试解决这个问题，并在找到后发布我的解决方案。在那之前。。。UseCookies必须这样做。

帐户是否设置为自己的应用程序？这可能会导致一个问题，因为用户正在达到一个可能意味着跨越某种边界的级别，但这只是我猜测的一个快速答案。当你说

正在传递正确的用户名和密码时

你的意思是你可以验证密码哈希匹配是否正确？您永远无法验证密码是否匹配。您确定URL可以在其他非ipad设备上访问吗？（你被你的授权规则咬了？@JB、克里斯和亚当：这是间歇性的错误。大多数情况下，它工作正常，但在iPad上偶尔会出现故障。它在铬上工作稳定。我的调查让我找到了IIS日志，在那里可以看到cookie到达，但显然没有得到正确的解释。url和密码匹配“大部分时间”都在工作。如果会话（或其他上下文）不可用，您是否有任何逻辑重定向到登录页面？如果cookie被发送过来，它应该被正确处理，这让我怀疑是不是其他原因导致了重定向。非常感谢。这让我快发疯了。更糟糕的是，我第一次注意到这个问题是在夏威夷度假时（而且比平时更多地使用iPad）。有一次我注意到，很难“精神上放下”并享受这次旅行。我真的很讨厌这样的虫子，把它从名单上划掉很好：-）太棒了。这个真的帮助了我。非常感谢。：）