时间戳

首页 > 解决方案 > 服务器如何知道使用凭据发送的请求？

http - 服务器如何知道使用凭据发送的请求？

问题描述

当通过我的网站从另一台服务器请求资源时，我遇到了一个问题。

我请求资源（通过 Range Requests 请求的 PDF 文件）。浏览器（本例中为 Chrome）向服务器发送一个 OPTIONS 请求。服务器从 OPTIONS 返回 200，但其中一个标头是 -Access-Control-Allow-Credentials: true 由于服务器公开了响应标头的通配符*，Access-Control-Allow-OriginChrome 然后（我认为）从服务器抛出以下响应并给我一个错误，说服务器可以如果发出请求，则不公开通配符withCredentials = 'include'。

现在，我没有withCredentials在我可以看到的代码中的任何地方设置标志，而且我似乎无法找出服务器如何知道是否发送了请求 withCredentials。我的 cookie 不会随 OPTIONS 或 GET/PARTIAL CONTENT 请求一起发送。我可以看到请求中没有其他特殊标头。

所以，

  1. 服务器如何知道以及我如何知道客户端的枯萎凭据设置为包括？

  2. 如果我没有在我这边设置凭据，是什么导致 Chrome 认为我正在使用的模式是withCredentials = 'include'？

  3. 服务器是否应该在Access-Control-Allow-Credentials: trueOPTIONS 之后发回所有请求的标头？

标签： httpcorsxmlhttprequesthttp-headers

解决方案

  1. 服务器如何知道以及我如何知道客户端的枯萎凭据设置为包括？

withCredentials接收服务器对客户端设置一无所知。服务器只是在请求中接收某种形式的凭据，或者不接收。就 CORS 协议而言，接收服务器不会根据请求是否包含凭据而改变其行为。接收服务器要么只发回Access-Control-Allow-Credentials: true响应头，要么不发回。

  1. 如果我没有在我这边设置凭据，是什么导致 Chrome 认为我正在使用的模式是withCredentials = 'include'？

答案是，它是主观的——这取决于服务器管理员打算为谁做出响应。但最佳实践是，您可能只想发回Access-Control-Allow-Credentials: true您知道并明确允许的特定来源。Access-Control-Allow-Origin: *这就是为什么 CORS 协议有这样的限制，即如果请求具有凭据并且响应具有（通配符）标头值，它将不允许您的前端代码访问响应。

  1. 服务器是否应该在Access-Control-Allow-Credentials: trueOPTIONS 之后发回所有请求的标头？

Chrome 只会认为如果模式真的是 withCredentials = 'include'. 因此，您的客户端代码的某些部分实际上正在设置withCredentials = 'include'- 或者，实际上withCredentials = 'include' 并没有全部设置，但您出于某种原因只是认为它是。

推荐阅读