关于SameSite更改与Chrome的混淆 [英] Confusion regarding SameSite changes with Chrome
问题描述
我需要一些帮助来理解我在描述Chrome的新SameSite限制的材料中找不到的情况。当前，我有一个托管站点的案例，该站点向API发出跨站点请求。该API使用CORS标头进行响应。详细信息如下：
I need some help understanding a case which I can not find described in material I have found describing the new SameSite restrictions for Chrome. Currently, I have a case where I have a site hosted which makes cross-site requests to an API. The API responds with CORS headers. The details are:
Site: https://a.a.com
API: https://b.a.com
--API response headers
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://a.a.com
--cookie previously set with
Set-Cookie: value=somevalue; Path=/; Expires=<some time/date>; HttpOnly
我不希望CORS标头会影响任何内容（基于我从未见过的一切）提到SameSite的更改），但无论如何我还是把它们放在这里。在这种情况下，当我在以下位置设置标志时：
I don't expect the CORS headers to impact anything (based on everything I have seen it never mentions the SameSite changes) but I am putting them here anyways. Given this scenario and when I set the flags at:
chrome://flags/#same-site-by-default-cookies
chrome://flags/#cookies-without-same-site-must-be-secure
我希望浏览器阻止发送cookie值。这是因为我希望cookie被视为具有SameSite = Lax，并且它们是跨站点请求。这不是实际发生的情况，并且cookie已成功发送。在测试时，我还尝试在任何请求和POST请求之间等待3分钟，以避免 Lax + POST缓解，因为我们在每个响应上都设置了cookie（具有更新的到期时间）。根据我正在阅读的有关更改的内容，我不明白为什么浏览器未阻止发送此cookie，以及为什么这些请求成功。
I would expect the browser to block the sending of the cookie value. This being because I would expect the cookie to be treated as if it had SameSite=Lax and that these are cross-site requests. This is not what actually happens and the cookie is sent successfully. When testing this, I also tried waiting 3 minutes between any requests and a POST request to avoid the "Lax+POST" mitigation as we set the cookie (with updated expiration) on every response. Based on what I am reading about the changes, I don't understand why the sending of this cookie is not blocked by the browser and why these requests succeed.
更令人困惑的是，在开发过程中我们会遇到以下情况：
To make things more confusing, we have some cases during development with the following scenario:
Site: http://localhost
API: https://a.b.com
--API response headers
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://localhost
--cookie previously set with
Set-Cookie: value=somevalue; Path=/; Expires=<some time/date>; HttpOnly
与上述第一种情况不同，这些请求实际上阻止了cookie的发送（仅当新的Chrome标记已启用）。如我所料，浏览器发出的警告消息与SameSite和Secure标志有关。
Unlike the first scenario described, these requests actually block the cookie from being sent as expected (only when new chrome flags are enabled). The warning message the browser gives is related to SameSite and Secure flags as I would expect.
有人可以帮我理解为什么第一种情况有效吗？我担心的是它实际上是一个错误，不应该。如果是这种情况，将来可能会在没有警告的情况下从工作变为失败。
Can someone help me understand why the first scenario is working yet the second is not? My concern is that it working is actually a bug and it shouldn't. If this is the case, it may be possible that in the future it might, without warning, go from "working" to "failing".
我在这里找到的Chrome更改/标志的详细信息：
Details of the Chrome changes/flags I found are here:
- < a href = https://www.chromestatus.com/feature/5633521622188032 rel = noreferrer> https://www.chromestatus.com/feature/5633521622188032
- https://www.chromium.org/updates/same-site
- https://web.dev/samesite-cookies-explained/
- https://www.chromestatus.com/feature/5633521622188032
- https://www.chromium.org/updates/same-site
- https://web.dev/samesite-cookies-explained/
推荐答案
如此处> https://web.dev/samesite-cookies-explained/ ：
如果用户在www.web.dev上并从
static.web.dev请求图像，则该请求是同一站点的请求。
If the user is on www.web.dev and requests an image from static.web.dev then that is a same-site request.
与您的第一种情况相同：
Same as your first case:
Site: https://a.a.com
API: https://b.a.com
因此，浏览器将您的第一个请求视为同一站点请求，并且不会删除Cookie，但是第二个请求是跨站点请求，没有相同站点属性的cookie将被删除。
So the browser considers your first request as a same-site request and cookies won't be removed, but the second one is a cross-site request and cookies without samesite attribute will be removed.
这篇关于关于SameSite更改与Chrome的混淆的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
