背景

我正在考虑实施方面SameSite今天我的饼干。我已经有了HttpOnly and Secure所以我想这可能没什么大不了的。

为什么它坏了

好吧，事实证明，一旦我实现了这个设置，很多东西就坏了。两者都发生了这种情况SameSite=Lax and SameSite=Strict。我做了一些研究，发现这是由于 SSO 很容易因 SameSite 设置而损坏Lax or Strict（相对于None):

• 即将到来的浏览器行为变化：开发人员需要了解什么 https://auth0.com/blog/browser-behavior-changes-what-developers-need-to-know/
• SameSite Cookie 属性：它是什么以及它为何重要 https://adzerk.com/blog/chrome-samesite/
• Microsoft Edge 即将发生影响网站兼容性的更改 https://learn.microsoft.com/en-us/microsoft-edge/web-platform/site-impacting-changes
• 微软警告 SameSite Cookie 更改可能会破坏某些应用程序 https://redmondmag.com/articles/2020/01/28/samesite-cookie-changes-break-apps.aspx
• 单点登录历险记：SameSite Doomsday https://charliedigital.com/2020/01/22/adventures-in-single-sign-on-samesite-doomsday/
• SameSite cookies 解释 https://web.dev/samesite-cookies-explained/

我的主要浏览器 (Iron 70) 基于 Chromium 70，因此我之前从未遇到过 2 月份向 Chrome 80 用户推出的更改，据说该更改默认没有 cookieSameSite价值观Lax。我安装了最新的 Google Chrome Portable 来查看它，有趣的是，该功能目前似乎是not（谢天谢地）默认为SameSite=Lax因为它可能已经习惯了 - 一旦我明确启用以下标头，我的网站就会在那里崩溃：

Header edit Set-Cookie ^(.*)$ $1;SameSite=Lax

看来这是因为没有明确的SameSite, Chromium 将其视为“洛杉矶国际机场 + 邮政后 2 分钟规则” https://groups.google.com/a/chromium.org/g/blink-dev/c/AknSSyQTGYs/m/YKBxPCScCwAJ?pli=1默认情况下（而且我正在快速测试，所以不到 2 分钟）。

即使Lax不过，我所有的单点登录都被破坏了，我的实时聊天也不再工作了——无论是使用 Websockets 还是 XHR 请求。当我尝试进行单点登录时，不知何故我最终退出了主网站，这也没有多大意义 - 基本上，一切都搞砸了。

1. 是否有希望让 XHR 或 Websockets 再次使用Lax？我已经聊天了chat.example.com，但我也允许在侧面板中访问它sub.someotherdomain.org。我的猜测是这里的答案是no，解决这个问题的唯一方法是在同一域上提供一个 URL，Apache 只是在幕后指向同一个脚本。烦人，但它could完成了-但是还有其他方法吗？

2. 我更大的问题是：单点登录本质上与Lax and Strict？我还没有真正发现太多这方面的内容。所有文章似乎都在讨论如何破坏 SSOLax不可避免的，甚至有一些图表可以解释why它会崩溃，但是 SSO 必须是这样吗？

主流解决方法

大多数网站都说要做SameSite=None解决这个问题并在所有用户代理中强制执行旧的行为。从技术上讲，这是可行的，但我想知道是否有任何希望能够使用Lax反而？如何才能使其发挥作用而不必屈服于SameSite=None?

TL;DR - 是的，你can use SameSite=Lax（但不是SameSite=Strict）并且不破坏 SSO！

有两件大事需要注意SameSite饼干：

• Lax禁止跨站请求使用POST
• Strict还禁止使用跨站点请求GET

A helpful summary:

_{Source: https://www.wst.space/cookies-samesite-secure-httponly/ https://www.wst.space/cookies-samesite-secure-httponly/}