在IE中将NTLM与表单身份验证混合(空POST问题)

时间:2013-08-30 15:20:48

标签: asp.net internet-explorer iis ntlm formsauthentication

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

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

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

登录程序的工作原理如下:

  1. 用户首先访问siteurl
  2. 用户被重定向到/ Intranet以检查集成的身份验证
  3. 如果接受了集成,用户可以使用适当的身份验证cookie重定向回siteurl并访问该网站
  4. 如果集成失败,用户将被重定向到siteurl / loginForm以手动填写凭据
  5. 我们在Internet Explorer(8,9,10)中遇到了一些问题,它们拒绝在步骤4提交表单数据。一旦NTLM协商开始,IE就不会将内容POST到未经身份验证的站点,这是一种已知行为为那届会议。我考虑了一些解决方法:

    1. 将凭据存储在cookie(使用JS)中,如果POST内容的长度为0,则在服务器上尝试检查cookie值。之后删除cookie
    2. 使用GET而不是POST发送凭据(丑陋,因为我们需要确保用户不会在浏览器地址栏中看到他刚发布的密码)
    3. 提供指向用户的链接以打开新选项卡并在单独的浏览器会话中继续执行身份验证过程(这似乎可以正常工作,因为IE很乐意从第二个选项卡发送POST数据)
    4. 我们可能还有其他选择来解决这个问题吗? 从上面的3中哪一个更可取,我们可能会遇到什么未考虑的陷阱?

1 个答案:

答案 0 :(得分:3)

我在这里写了这个问题:http://blogs.msdn.com/b/ieinternals/archive/2010/11/22/internet-explorer-post-bodies-are-zero-bytes-in-length-when-authentication-challenges-are-expected.aspx

您的问题省略了重要信息,这使得难以排除故障。您永远不会看到您使用的文字网址所描述的问题,因为IE使用保护空间来决定网站是否要通过HTTP请求凭据/ 401和example.com/example.com/foo/是不同的保护空间。

如果您可以共享此方案的Fiddler日志以便更好地进行故障排除,那将非常有用。