SameSite属性对于Cookies的概念确实很难理解...
为了应对Chrome 80的更改，我正在尝试衡量缺少SameSite属性对我的cookies的影响。我有以下配置：
Set-Cookie: SomeCookie=value; path=/; secure; httponly)并重定向到auth.mysite.com因为在main.mysite.com和auth.mysite.com之间的重定向被视为同一站点，并且因为Chrome 80将缺少SameSite属性视为SameSite=Lax，所以这样做是可以正常工作的。
然而，当main.mysite.com嵌入到托管在另一个站点（比如othersite.com）上的页面中时，SomeCookie不会在步骤3中发送回main.mysite.com：
这是正常的吗？为什么会这样？
上面的回答是不正确的...让我澄清一些混淆点。
1. 在SameSite中，什么情况下两个站点被视为“同一站点”？
无论cookie的Domain属性如何，当两个站点的eTLD+1（也称可注册域）相同时，它们被认为是相同的。有关更详细的说明，请参见我的答案这里。
因此，在这种情况下，假设eTLD为“.com”，我们会认为auth.mysite.com和main.mysite.com是同一个站点，因为它们的eTLD+1都是mysite.com。另一方面，anything.mysite.com和othersite.com始终是跨站点的。无论是顶级导航还是子资源请求（例如iframe中的图像或文档），这都是正确的。
2. Domain属性是什么意思？
如果使用Set-Cookie：cookiename=cookievalue; Domain=mysite.com设置了cookie，则该cookie将在发送到匹配*.mysite.com的任何域的请求上发送（即所有子域）。
这是调整cookie范围的一种方式。例如，您可以使用Domain=mysite.com设置全局cookie，所有您的域都关心，以及Domain=corp.mysite.com用于所有公司内部域都关心的cookie（但不包括您的外部面向域，例如）。
默认情况下（对于未明确设置Domain属性的cookie），仅将cookie发送到设置cookie的域。 （没有子域。）
您无法设置与请求URL不匹配的Domain属性。
（此外，不存在cookie的“origin”属性。）
3. 那么Domain与SameSite有什么关系？
没有关系。它们是独立的cookie属性。Domain不关心同一站点/跨站点上下文，而SameSite不关心cookie的域/子域范围。
4. 当mysite.com嵌入othersite.com的iframe中时，默认的Lax cookie为什么不会被发送？
这被视为跨站点上下文，因为用户URL栏中的站点是othersite.com，而请求是针对mysite.com进行的，这两个站点具有不同的eTLD +1。
因为它在iframe中，所以这不是顶级导航，因此所有跨站点请求都将排除SameSite cookie。
如果它是一个顶级导航（用户单击链接从othersite.com转到mysite.com），那么请求方法将很重要。在绝大多数情况下，这将是一个GET请求，因此处于Lax模式的cookie将会被发送。
希望这可以帮助您！您可以参考最新版本的规范获取更多详细信息。