昨天加班被一个问题困住了好久
问题描述
与同事调cas登录，用的方式为使用iframe访问后台一个接口，为了让iframe自动跳转到cas最终带回cookie，这样后边的接口都可以带着cookie进行访问了。但问题是我机器一直在页面和cas登录页面来回跳，但我同事的机器没有问题。
问题定位
我的机器是chrome92，我同事的机器是chrome64，通过对比两个人的网络请求参数发现，我的iframe请求跳转到cas登录页面没有带着cookie信息，而我同事的带着cookie信息
问题解决
现在知道是什么原因导致的了，现在来处理一下。通过网络查询，chrome 78~91之间的版本可以通过将SameSite by default cookies、Cookies without SameSite must be secure（chrome://flags/）这两项设置为disable来解决。恰巧我的版本是92，网有说可以通过在快捷方式上增加--disable-features=SameSiteByDefaultCookies参数来解决。亲试成功了！！！
原因
应用网友的描述：
Cookie 的SameSite属性用来限制第三方 Cookie，从而减少安全风险。它可以设置三个值：
Strict
Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。
Set-Cookie: CookieName=CookieValue; SameSite=Strict;
复制代码这个规则过于严格，可能造成非常不好的用户体验。比如，当前网页有一个 GitHub 链接，用户点击跳转就不会带有 GitHub 的 Cookie，跳转过去总是未登陆状态。
Lax
Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。
Set-Cookie: CookieName=CookieValue; SameSite=Lax;
复制代码设置了Strict或Lax以后，基本就杜绝了 CSRF 攻击。当然，前提是用户浏览器支持 SameSite 属性。
None
网站可以选择显式关闭SameSite属性，将其设为None。不过，前提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。
Set-Cookie: widget_session=abc123; SameSite=None; Secure
chrome升级到80版本之后(准确的说是78版本之后)，cookie的SameSite属性默认值由None变为Lax，这个才是本次事件的根本原因。
