2

我们的 ASP.NET 应用程序托管在 IIS 7.5 中，并具有以下设置：

  • 主站点托管在根 IIS 文件夹下，可通过http://siteurl(1)访问
  • http://siteurl/Intranet我们在(2)下托管的同一个 AppPool 中有一个单独的应用程序

主应用程序 (1) 与表单身份验证 (url: siteurl/loginform) 一起启用了匿名身份验证。第二个应用程序 (2) 具有集成身份验证 (NTLM)。

登录过程如下：

  1. 用户先去siteurl
  2. 用户被重定向到 /Intranet 以检查集成身份验证
  3. 如果集成被接受，用户将使用正确的身份验证 cookie 重定向回 siteurl 并访问该站点
  4. 如果集成失败，用户将被重定向到 siteurl/loginForm 以手动填写凭据

我们遇到了 Internet Explorer (8, 9, 10) 的一些问题，它拒绝在第 4 步提交表单数据。一旦为该会话开始 NTLM 协商，IE 将不会将内容发布到未经身份验证的站点似乎是一种已知行为. 我为此考虑了一些解决方法：

  1. 如果 POST 内容的长度为 0，则将凭据存储在 cookie 中（使用 JS）和服务器上，尝试检查 cookie 值。之后删除cookie
  2. 使用 GET 而不是 POST 发送凭据（很难看，因为我们需要确保用户在浏览器地址栏中看不到他刚刚发布的密码）
  3. 向用户提供一个链接以打开一个新选项卡并在单独的浏览器会话中继续身份验证过程（这似乎可以工作，因为 IE 会很乐意从第二个选项卡发送 POST 数据）

是否有任何其他选择可以解决这个问题？从上述 3 中，哪一个更可取，我们可能会遇到哪些未考虑的陷阱？

4

1 回答 1

3

我在这里写过这个问题：http: //blogs.msdn.com/b/ieinternals/archive/2010/11/22/internet-explorer-post-bodies-are-zero-bytes-in-length-when-authentication -挑战是预期的.aspx

您的问题遗漏了重要信息，因此难以排除故障。您永远不会看到您使用的文字URL 描述的问题，因为 IE 使用保护空间来决定站点是否将通过 HTTP/401 要求凭据，example.com/并且example.com/foo/是不同的保护空间。

如果您可以共享此场景的 Fiddler 日志以便更好地进行故障排除，这将非常有帮助。

于 2013-08-30T19:53:25.463 回答