Fatal编程技术网
  • http/
  • Http 设置Cookie标头不跨域工作

Http 设置Cookie标头不跨域工作

http cookies cors

Http 设置Cookie标头不跨域工作,http,cookies,cors,cross-domain,Http,Cookies,Cors,Cross Domain,我在一个网站https://aaa.shared.com。此网站（称之为A）向url发送xhr请求https://zzz.shared.com/some/path（网站Z）并收到带有以下标题的响应： access-control-allow-credentials: true access-control-allow-origin: aaa.shared.com set-cookie: foo=bar; expires=Fri, 01 Jan 2100 00:00:00 GMT; path=/;

我在一个网站
https://aaa.shared.com
。此网站（称之为
A
）向url
发送
xhr
请求https://zzz.shared.com/some/path
（网站
Z
）并收到带有以下标题的响应：

access-control-allow-credentials: true
access-control-allow-origin: aaa.shared.com
set-cookie: foo=bar; expires=Fri, 01 Jan 2100 00:00:00 GMT; path=/; secure; samesite=none; httponly
（我随后添加了
访问控制
标题）

现在，我所期望的是，无论何时我在A或Z上，无论何时请求转到Z（跨来源或同一来源，重要的是请求的URL），浏览器都会添加cookie，但它不会！此外，我无法在浏览器开发工具（F12->Application->Cookie）中看到它的设置。我正在使用Chrome，但目标是跨浏览器解决方案

我错过了什么？我发现在请求不同来源时，很难找到有关
Set Cookie
头如何工作的详细信息

编辑：
rowan_z
最初建议将
samesite=lax
替换为
samesite=none
，因为这个问题的第一个版本中的A和z是完全独立的域（仅共享
.com
部分）。我试过了，但没用。但现在我意识到它们实际上被视为
SameSite
，因为它们位于
shared.com
域的不同子域上。所以现在我相信
samesite=lax
也应该在这里起作用

更新：
最后，我只是将应用程序
aaa.shared.com
移动到同一子域下，使用一些路径
zzz.shared.com/aaa/path
，因为处理cookie和COR非常困难。此外，将其配置为与
localhost
一起使用会增加额外的复杂性。

您已经明确声明了
SameSite=Lax
，它限制cookie在跨站点请求时发送。这看起来像是希望
SameSite=None
允许这些cookie的情况

更多详细信息：

您所做的所有事情都是使其正常工作所必需的：

  • 访问控制允许凭据：true
  • 访问控制允许来源：aaa.shared.com
    （非通配符）
  • 安全
  • SameSite=None
发送请求时您只缺少一件事：

我创建了一个模拟端点，您可以使用它来测试这行代码两次（在另一个域的控制台中）：

您会注意到cookie将在第二次发送

如果模拟端点过期（不知道它会持续多久），或者有人破坏它，您可以在头配置中使用此JSON重新创建它：

{
    "Content-Type": "application/json",
    "Set-Cookie": "test=value; Path=/; Secure; SameSite=None;",
    "access-control-allow-origin": "https://yourdomain",
    "Access-Control-Allow-Credentials": "true"
}
嗨，谢谢，好地方。我在你的文章中添加了
samesite=none
。不幸的是，这似乎并不能解决我的问题。cookie还没有设置好，也没有发送任何想法，这里可能会发生的其他事情将非常值得赞赏。事实上，这可能更有趣，我已经更新了问题。我的域A和域Z可能是
SameSite
，因为看起来像
xxx.sss.com
和
yyy.sss.com
（它们是同一
sss.com
domain`的子域）将cookie的域设置为“shared.com”，如下所述：您根本没有设置域属性，因此默认情况下它可能设置为“aaa.shared.com”谢谢。另一点我必须弄清楚的是，在这种情况下，浏览器实际上发送了一个
选项
请求，请求
获取
（我想这是因为我们需要凭据）。Chrome最近使
OPTIONS
请求在开发工具中不再可见，因此我得到的错误有点误导，因为它似乎在抱怨
GET
响应，而实际上它在抱怨OPTIONS请求。意识到这一点，我只是在“是”之后重新启用了
OPTIONS
请求跟踪
选项
是因为cookie使请求“非简单”（这是HTTP规范中的一个术语），并触发飞行前请求，以检查端点是否确实接受我们将要发送的请求。这在这里解释得非常清楚： 
{
    "Content-Type": "application/json",
    "Set-Cookie": "test=value; Path=/; Secure; SameSite=None;",
    "access-control-allow-origin": "https://yourdomain",
    "Access-Control-Allow-Credentials": "true"
}