javascript - 使用来自子域的请求发送 cookie

Question

我们有以下配置:testing.parentdomain.com当您访问此域并创建一个购物篮时，我们会创建一个为购物篮值(value)存储的 cookie。 cookies domain设置为 .testing.parentdomain.com ，它是 Httponly，路径为 /我们有一个想要访问 cookie 的子域。 subdomain.testing.parentdomain.com此子域调用父域上的端点，例如:testing.parentdomain.com/basketData .此调用是返回 JSON 的 GET 请求。
问题
问题是子域在发出请求时似乎没有发送 cookie 值，因此我们没有得到预期的响应。
尝试
查看其他问题，我们尝试了 CORS 和凭证更改。
作为附加说明，我们将以下 JS 与 webpack/babel 捆绑在一起。
我们的请求来自 AJAX，如下所示:

  $.ajax({
    url: url,
    type: 'GET',
    xhrFields: {
      withCredentials: true
    },
    crossDomain: true
  })

服务器为子域和允许凭据设置了 CORS。在响应中，我们可以看到这些被返回。
访问控制允许凭据:真
访问控制允许来源: 来自上方的子域
是否有任何原因没有将 cookie 与请求一起发送到父域？我们已经在服务器端响应中注销了 cookie，但它们并不像我们预期的那样存在。
请求 header
:authority: testing.parentdomain.com
:方法:获取
:路径:/篮子/数据/
:方案:https
接受:/
接受编码:gzip、deflate、br
接受语言:en-GB,en;q=0.9,en-US;q=0.8
产地: https://subdomain.testing.parentdomain.com
推荐人: https://subdomain.testing.parentdomain.com/
sec-fetch-dest:空
秒取模式:cors
sec-fetch-site:同一站点
用户代理:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36
响应 header
访问控制允许凭据:真
访问控制允许方法:GET、PUT、POST、DELETE、HEAD、OPTIONS
访问控制允许来源: https://subdomain.testing.parentdomain.com
缓存控制:无缓存，无存储
内容长度:2238
内容类型:应用程序/json；字符集=utf-8
日期:格林威治标准时间 2020 年 11 月 3 日星期二 20:39:36
过期:-1
杂注:无缓存
服务器:Microsoft-IIS/10.0
设置cookie:AWSALB=N0bcThdgRFzrSfQVNIsffgsvY6T/y2Bp47RZJCueeSLOS7eEjo0AThiElXmww6fy2eynRyyt8gAB8di/Mqy1x+Ds8Ig1TumKkWnQiFvIkoELI/rEYYgyUxbEtUI4；到期=格林威治标准时间 2020 年 11 月 10 日星期二 20:39:36；路径=/
设置cookie:AWSALBCORS=N0bcThdgRFzrSfQVNIsffgsvY6T/y2Bp47RZJCueeSLOS7eEjo0AThiElXmww6fy2eynRyyt8gAB8di/Mqy1x+Ds8Ig1TumKkWnQiFvIkoELI/rEYYgyUxbEtUI4；到期=格林威治标准时间 2020 年 11 月 10 日星期二 20:39:36；路径=/;相同站点=无；安全的
状态:200
严格的传输安全:max-age=31536000；
变化:起源
x-content-type-options: nosniff
x 框架选项:SAMEORIGIN
x-机器人标签:noindex
x-ua 兼容:IE=edge
x-xss-保护:1；模式= block

Answer 1

即使您从子域调用主域，这也被视为跨域请求。
引自 RFC 6454这符合“起源”术语:

Q: Why use the fully qualified host name instead of just the "top-
level" domain?

A: Although the DNS has hierarchical delegation, the trust
relationships between host names vary by deployment. For example, atmany educational institutions, students can host content at
https://example.edu/~student/, but that does not mean a document
authored by a student should be part of the same origin (i.e.,
inhabit the same protection domain) as a web application for managinggrades hosted at https://grades.example.edu/.

所以你所做的一切确实是 必填 使其工作:

access-control-allow-credentials: true

access-control-allow-origin: subdomain.testing.parentdomain.com (不是通配符)

withCredentials: true在请求中

SameSite=None 在这种情况下不需要 cookie 属性，因为从子域到同一域的另一个子域的请求被视为“同一站点”( Source )。
因此，只需检查一切是否正确设置，它应该可以正常工作。