ajax 请求需要 401 授权,但重试成功

发布于 2024-12-18 03:40:11 字数 352 浏览 1 评论 0原文

我们在服务器上使用 apache 和 NTLM:

NTLMAuth on
AuthType NTLM
AuthName "Auth"
NTLMAuthHelper "/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp"
NTLMBasicAuthoritative on
require valid-user

当我们使用 ajax 时,这会出现错误,大多数 ajax 请求在第一次尝试时失败,并显示消息“401需要授权”,但在自动重试时它们会成功,为什么之间有区别两个请求?

我们的应用程序可以工作,但这个错误很烦人,占用资源并减慢应用程序的速度。

We use apache with NTLM on our server:

NTLMAuth on
AuthType NTLM
AuthName "Auth"
NTLMAuthHelper "/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp"
NTLMBasicAuthoritative on
require valid-user

And this gives as an error when we use ajax, most of our ajax requests fail on the first try with message "401 Authorization Required" but on automatic retry they succeed, why is there a difference between both requests?

Our application works but this error is annoying, uses resources and slows down application.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

楠木可依 2024-12-25 03:40:11

我怀疑您实际看到的不是某种“自动重试”行为,而是挑战-NTLM的响应认证。就其性质而言,您必须为连接上的第一个请求添加额外的往返。身份验证应该如下所示:

  1. 客户端请求受 NTLM 身份验证保护的资源。
  2. 服务器将回复 401 未经授权,并指示它支持的机制(在本例中为 NTLM)。
  3. 客户端使用初始 NTLM 身份验证消息(“类型 1”消息)请求资源,其中包含用户的域和用户名以及客户端的功能。
  4. 服务器以 401 未经授权和 NTLM 质询(“类型 2”消息)进行响应。
  5. 客户端计算对服务器质询的响应,然后使用最终的 NTLM 身份验证消息(“类型 3”消息)请求资源。
  6. 服务器以适当的代码进行响应 - 如果身份验证未成功,这将是 401,如果身份验证成功,这将是成功,未找到,等等。

所以是的,您将使用一些额外的资源来进行 NTLM 身份验证(无论如何,使用基本身份验证。)但请注意,NTLM 验证连接而不是请求。因此,通过同一保持活动 HTTP 连接的后续请求不需要重新进行身份验证。这减轻了挑战-响应性质的负担。

最后,请注意,大多数支持 NTLM 或 SPNEGO 的 Web 浏览器都为此做好了准备,并将使用 Expect/Continue。因此,它们不会在初始连接中发送 POST 数据(例如),直到它们通过身份验证并从服务器获得 HTTP 继续,这也应该减轻负担。

I suspect what you're actually seeing is not some sort of "automatic retry" behavior, but is the challenge-response authentication of NTLM. By its nature, you will have to add an extra round-trip to the first request on a connection. The authentication should look like this:

  1. Client requests a resource that is protected by NTLM authentication.
  2. The server will reply with a 401 unauthorized and indicate the mechanisms that it supports (in this example, NTLM).
  3. The client requests the resource with the initial NTLM authentication message (the "type 1" message) which contains the user's domain and username as well as the capabilities of the client.
  4. The server responds with a 401 unauthorized and the NTLM challenge (the "type 2" message).
  5. The client computes a response to the server's challenge, and then requests the resource with the final NTLM authentication message (the "type 3" message).
  6. The server responds with the appopriate code - if the authentication did not succeed, this will be a 401, if the authentication did succeed, this will be success, not found, etc.

So yes, you will use some additional resources to do NTLM authentication (over using Basic authentication, anyway.) Note, however, that NTLM authenticates a connection not a request. Thus, subsequent requests over the same kept-alive HTTP connection do not need to reauthenticate. This lessens the burden of the challenge-response nature.

Finally, note that most web browsers that support NTLM or SPNEGO are prepared for this, and will use expect/continue. Thus, they will not send POST data (for example) in the initial connection until they're authenticated and get an HTTP continue from the server which should also lessen the burdern.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文