ajax 发布到 SharePoint Web 服务因 ntlm 挑战而中断
我有一个 Web 部件,在 UI 的实现中大量使用 JavaScript。它还使用对某些 SharePoint Web 服务的异步 XmlHttpRequest 请求(顺便说一句,我正在使用 SPServices)。
对于某些请求,用户面临 NTLM 身份验证质询,输入凭据后,请求完成。尽管有超过 3 个请求,但在一页加载时这种情况会发生 3 次。有几件事让我感到困惑:
- 正如我所说,并非所有请求都有这个问题,
- 用户已经通过 NTLM 身份验证访问了该站点,那么为什么 ajax 请求会受到质疑?
- 这是在 Windows 域环境中。在无域环境下,不存在这个问题(虽然两者都使用了Windows auth)。
当然,这一切都是在IE中进行的。我尝试过的一件事是将 NTLM 身份验证标头插入到 ajax 请求中,但这并没有改变任何东西(我真的不认为会改变,但值得一试)。
有什么建议吗?
I've got a web part that uses javascript heavily in the implementation of a UI. It also makes use of asynchronous XmlHttpRequest requests to some of the SharePoint web services (I'm using SPServices, btw).
For some requests, the user is confronted with NTLM authentication challenges, and after entering credentials, the request completes. This happens 3 times on one page load, although there are more than 3 requests. There are several things about this that I find confusing:
- as I said, not all requests have this problem
- the user has already accessed the site with NTLM authentication, so why do the ajax requests get challenged?
- This is in a Windows domain environment. In a non-domain environment, this problem does not exist (although Windows auth is being used in both).
Of course, all of this is in IE. One thing I tried was to insert the NTLM authentication header into the ajax request, but that didn't change anything (I didn't really think it would, but it was worth a try).
Any suggestions?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
不应该是这样的。 Windows 身份验证是针对每个进程的,如果您已经通过身份验证,那么当您再次加载某些内容时,您将保持身份验证,无论它是浏览器的主连接还是 XHR 请求。
我在我们的一台测试服务器中看到了这种奇怪的行为。在这种情况下,对 SharePoint 的 WebDAV 访问也被破坏,有时您无法访问
\\sharepointserver\sites\somesite
路径(但几分钟后您可以再次访问)。在这种情况下,Kerberos 身份验证似乎出现了问题,有时会发出错误的令牌。但是,我们没有解决这个问题,只是安装了一台新服务器并向其附加了内容数据库。这有效:-)It should not be this way. Windows auth is per-process and, if you are already authenticated, you remain authenticated when you load something again, does not matter if it is the browser's main connection or an XHR request.
I have seen this strange behavior in one of our test servers. In that case, also WebDAV access to SharePoint was broken and some times you could not access the
\\sharepointserver\sites\somesite
paths (but some minutes later you could do it again). It seemed that there was somehing wrong with Kerberos authentication in that case and that wrong tokens were issued sometimes. However, we didn't solve that, just installed a new server and attached content databases to it. That worked :-)使用:传输 clientCredentialType="Windows"
检查 http:// msdn.microsoft.com/en-us/library/bb226411(BTS.20).aspx 了解更多信息
Use: transport clientCredentialType="Windows"
Check http://msdn.microsoft.com/en-us/library/bb226411(BTS.20).aspx for more info
Internet Explorer 会记住它是否对给定站点进行了 NTLM 身份验证。如果它被要求 POST 到该站点,它将期望该站点重新对其进行身份验证。如果网站不这样做,浏览器将不会在帖子正文中发送任何详细信息。
Internet Explorer remembers if it has NTLM-authenticated to a given site. If it is ever asked to POST to that site, it will expect the site to re-authenticate it. If the site doesn't, the browser won't send any details in the body of the post.
该问题是由于HTTP1.1会话超时造成的。
当您首次登录到经过 NTLM 身份验证的站点时,将打开一个 HTTP 会话。此会话经过身份验证,并且您在此会话打开时发出的每个请求都将使用该会话的 NTLM 令牌自动进行身份验证。
现在,当您发出 XmlHttpRequest 时,如果 HTTP 会话仍然打开,那么您的请求不会要求任何身份验证,因为它已准备就绪。
但是,如果会话以某种方式过期或关闭。然后系统会提示您登录。
为了更好地理解这一点,只需快速搜索 HTTP1.1 协议,您就会更好地明白我在说什么。
This problem is due to the HTTP1.1 session timeout.
When you first login to your NTLM authenticated site, a HTTP session is open. This session is authenticated, and every request you made while this session is open, will be automatically authenticated with the NTLM token of the session.
Now when you make the XmlHttpRequest, if the HTTP session is still open then your request doesn't ask for any authentication because it is allready.
But if the session expire or close for one way or another. Then you will be prompted for loggin.
To better understand that just make a quick search for HTTP1.1 protocol and you'll better see what I'm talking about.