第三方 Cookie 限制引发 Chrome 中的 SameSite 乌龙事件

各位技术大咖们，大家是否遇到过这样的难题：某天，一个你已经很久没改过的登录页面，突然出现了这样的情况——用户登录成功后，却莫名其妙地又跳回了登录页？今天，笔者就来跟大家分享一个由 Chrome 中 SameSite 引发的乌龙事件，希望能为遇到类似问题的开发者们提供一些思路和借鉴。

事件回放

最近，我在调试一个好久没改动的登录页面时，遇到了一个非常奇怪的问题：用户登录成功后，页面会立即重定向到目标页面，但随后又会再次验证登录状态，最终又跳回登录页。这一系列操作让我百思不得其解，于是开始了一番排查。

一番排查后，我猜测这个问题可能与 SameSite 有关。SameSite 是一种由浏览器强制实施的机制，用于限制第三方 Cookie 的发送。而我所使用的 Chrome 浏览器版本为 80，正好引入了这一新特性。

SameSite 机制

简单来说，SameSite 机制会对 Cookie 的发送行为进行限制，以防止跨站请求伪造 (CSRF) 攻击。它主要有三种模式：

• Strict（严格模式）： 仅允许同源请求发送 Cookie。
• Lax（宽松模式）： 同源请求和跨源 GET 请求可以发送 Cookie。
• None（无模式）： 所有请求都可以发送 Cookie。

在 Chrome 80 中，对第三方 Cookie 的默认 SameSite 模式被设置为 Strict。这意味着，对于那些不是由当前页面设置的 Cookie，只有同源请求才能发送它们。

乌龙原因

回到我们的登录页面问题，登录成功后，页面会重定向到目标页面 video.m.abc.com。而由于这是一个跨域请求，因此根据 SameSite Strict 模式，浏览器不会发送包含用户登录信息的 Cookie。而目标页面在再次验证登录状态时，发现没有 Cookie，自然就又跳回了登录页。

解决方案

知道了问题的根源，解决方法也就变得简单了。我们只需要在设置 Cookie 时，明确指定其 SameSite 模式为 Lax 或 None，即可允许跨域请求发送 Cookie。具体代码如下：

Set-Cookie: login_token=abcdefg; SameSite=Lax

修改完代码后，重新测试登录页面，问题果然迎刃而解。用户登录成功后，可以正常跳转到目标页面，且不会再次验证登录状态。

总结

通过这次乌龙事件，我们深刻地体会到了浏览器更新对网站开发的影响。作为一名开发者，我们不仅要紧跟浏览器的最新动态，还要时刻关注其对我们网站可能产生的影响。只有这样，才能避免类似的乌龙事件发生，保证网站的稳定运行。

希望这篇文章能给大家带来一些帮助，也欢迎大家在评论区分享自己的经验和见解。