7 http httpresponse same-origin-policy cors fetch-api
MDN说，当必须在站点之间交换 cookie、授权标头或 TLS 客户端证书等凭据时，Access-Control-Allow-Crendentials必须将其设置为true.
考虑两个站点 A - https://example1.xyz.com，另一个站点是 B- https://example2.xyz.com。现在我必须Get从 A 向 B发出 http请求。当我从 AI 请求 B 时，
“请求的资源上不存在‘Access-Control-Allow-Origin’标头。因此不允许访问Origin‘http://example1.xyz.com ’。”
所以，我在 B 中添加以下响应头
response.setHeader("Access-Control-Allow-Origin", request.getHeader("origin"));
这解决了相同的起源错误，我可以向 B 提出请求。我何时以及为什么应该设置
response.setHeader("Access-Control-Allow-Credentials", "true");
当我用谷歌搜索解决这个same-origin错误时，他们中的大多数人都推荐使用这两个标题。我不清楚使用第二个Access-Control-Allow-Credentials。
Access-Control-Allow-Origin为origin从请求头中获取而不是通配符*？请给我举个例子，以便更好地理解它。
小智 6
如果您希望请求也能够发送 cookie，则需要 Allow-Credentials。如果您需要授权传入的请求，基于会话 ID cookie 将是一个常见的原因。
设置通配符允许任何站点向您的端点发出请求。如果请求与您定义的白名单匹配，则将允许设置为原点是很常见的。某些浏览器会缓存允许响应，如果您也从另一个域请求相同的内容，这可能会导致请求被拒绝。
设置Access-Control-Allow-Credentials: true实际上有两个作用：
Set-Cookie响应头实际上具有设置 cookie 的效果（Set-Cookie否则响应头将被忽略）这些影响与设置XMLHttpRequest.withCredentials或credentials: 'include'(Fetch API) 的影响相结合，导致凭据（HTTP cookie、TLS 客户端证书和身份验证条目）实际上被包含为请求的一部分。
https://fetch.spec.whatwg.org/#example-cors-with-credentials在 Fetch 规范中有一个很好的例子
| 归档时间： |
|
| 查看次数： |
10239 次 |
| 最近记录： |