4

我正在处理的应用程序面临 Ajax 问题。Web 应用程序是用 ASP.NET 4.5 编写的，它更具体地派生自 Visual Studio 2012 中的默认 MVC 示例应用程序。该应用程序托管在本地 IIS 服务器上（不是快速版本），并且需要 Windows 身份验证（当前为 NTLM）出于安全原因冒充客户。

我这里有 2 个问题。

  1. 该网站在浏览时正确地对客户端进行身份验证，但由于某种模糊的原因，每个 Ajax 调用都会在 401 Unauthorized 错误中失败（它在使用匿名身份验证时工作，所以我猜凭据没有封装在请求中？！）。我还没有时间调查他们之间的交流，但我相信这里的一位大师能够提供帮助。

  2. 最后，Windows 身份验证提供程序将移至 kerberos。关于这个 Ajax 问题有什么特别要注意的吗？

如果您需要任何其他信息，请告诉我。

编辑 1

我觉得很愚蠢......重新启动IIS解决了这个问题。有时它是一种乐趣......

感谢大家。

4

1 回答 1

6

下面的答案是基于我对 NTLM/Kerberos 的理解以及对 XmlHttpRequest 如何重用浏览器已知信息的一些推测。但是，我实际上并没有尝试重现您的场景，因此很可能我错了。

好的，到此为止。NTLM 会话是一个面向连接的协议。这意味着如果您的服务器不断返回“Keep-alive”并且客户端重复使用相同的连接，则无需再次进行身份验证握手。但是，就像连接关闭并再次打开一样，需要进行新的握手。只要这是请求服务器的浏览器，新的握手就会使用缓存在浏览器内存中的凭据自动完成，即您在初始握手时提供的确切凭据。

这就是为什么我认为您的 ajax 调用不起作用的原因——它可能只是打开了一个新连接并需要一个新的握手（而且似乎由于某种原因它没有重用缓存在浏览器内存中的凭据）。

但是，如果您切换到 Kerberos，这应该会改变。Kerberos 基于质询-响应模式，其中浏览器和服务器直接联系身份验证机构。然后，kerberos 将您的身份验证保存在带有票证的 http 标头上。有可能标头会自动附加到您的 AJAX 请求中。

请注意，与 NTLM 相反，Kerberos 仅在浏览器和服务器都可以联系身份验证机构时才有效。这就是为什么通常在 IIS 中将“协商”设置为身份验证方案 - 如果身份验证权限不能直接用于浏览器，这会首先尝试 Kerberos，然后切换回 NTLM。

于 2013-01-23T14:52:46.937 回答