不少用户升级到了 Chrome 80 版本以后发现登入公司的聚合类中台项目成功之后，打开内部嵌套的一个 iframe OA 应用但还是让输入用户名密码登录。这个情况是什么原因导致的？如何解决？
定位问题
- 第一步，认为可能是自身认证体系出了问题，于是查看用户电脑上的浏览器，发现浏览器通过中台前端页面打开 iframe 嵌套的 OA 应用，OA 的链接上有带 OA 的认证参数。直接用该链接打开 OA 的网页是会做到免密登录的。
- 第二步，单独通过网页直接打开 OA 链接，在 DevTools 里查看 Application，发现 Cookies 里是有用户的认证信息等相关参数的。但是如果通过中台打开 OA，发现 OA 的 Cookies 里没有数据。
- 第三步，而且最近没发什么重大改动的版本，排除了服务器或者程序的问题。那么顺着这条路子，初步怀疑应该是浏览器的原因。最后发现是 Chrome 80 版本的一个新特性搞的鬼。
解决方案
先说解决方案。
准确定位到问题，就好办了。这里想到了三种解决方法：
- 让用户直接访问 aaaa.com 这个网址的中台。因为自从中台迁移 IDC 后，中台相关的项目都统一在 aaaa.com 这个域名下，OA 也是。所以访问这个域名下的易道因为是在同一个主域名下，所以这个问题就避免了。但是如果用户访问的是 bbbb.com 这个网址的话， 里面的 OA 因为和该网址不是同一个主域名，所以会有跨域问题，导致 OA 的Cookies 设置不上。
- 浏览器显式关闭该功能。
- 地址栏输入：
chrome://flags/ - 找到
SameSite by default cookies和Cookies without SameSite must be secure - 将上面两项设置为
Disable即可。
- 显示关闭
SameSite属性，按照上述有效响应头设置登录接口的响应头即可。将SameSite属性值改为None, 同时将secure属性设置为true。且需要将后端服务域名必须使用https协议访问。由于设置SameSite = None，有SCRF风险，所以，最佳方案是使用token代替现有的Cookie方式作验证。
//...
response.setHeader(name: "Set-Cookie", value: "_u=xxxx; Path=/Login; SameSite=None; Secure")
//...
在 Chrome 80 版本中，Chrome 会将没有声明
SameSite值的cookie默认设置为SameSite=Lax。只有采用SameSite=None; Secure设置的cookie可以从外部访问，前提是通过安全连接（即HTTPS）访问。
那这 SameSite 又是什么？
什么是 SameSite
SameSite 是 Cookie 中的一个属性，它用来标明这个 cookie 是个 “同站 cookie”，“同站 cookie” 只能作为第一方cookie，不能作为第三方cookie，因此可以限制第三方 Cookie，解决 CSRF 的问题。不知道 CSRF 的看着这个。早在 Chrome 51 中就引入了这一属性，但是不会默认设置，所以相安无事。
第三方 Cookie：由当前
a.com页面发起的请求的URL不一定也是a.com上的，可能有b.com的，也可能有c.com的。我们把发送给a.com上的请求叫做第一方请求（first-party request），发送给b.com和c.com等的请求叫做第三方请求（third-party request），第三方请求和第一方请求一样，都会带上各自域名下的cookie，所以就有了第一方cookie（first-party cookie）和第三方cookie（third-party cookie）的区别。上面提到的CSRF攻击，就是利用了第三方cookie可以携带发送的特点 。
“同站 cookie” 不是根据同源策略判断，而是 PSL（公共后缀列表），子域名可以访问父域名 cookie，但父域名无法访问子域名 cookie。
SameSite 总共有三个值：Strict、Lax、None。以下内容引自阮一峰博客
Strict
Strict 最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。
Set-Cookie: CookieName=CookieValue; SameSite=Strict;
这个规则过于严格，可能造成非常不好的用户体验。比如像本人当前遇到的现象，cookie 带不过，等于一直没有登录状态，就会回到登录页。
Lax
Lax 规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。Chrome 80 之后默认设置为该值。
Set-Cookie: CookieName=CookieValue; SameSite=Lax;
导航到目标网址的 GET 请求，只包括三种情况：链接，预加载请求，GET 表单。详见下表。
| 请求类型 | 示例 | 正常情况 | Lax |
|---|---|---|---|
| 链接 | <a href="…"></a> | 发送 Cookie | 发送 Cookie |
| 预加载 | <link rel="prerender" href="…"/> | 发送 Cookie | 发送 Cookie |
GET 表单 | <form method="GET" action="…"> | 发送 Cookie | 发送 Cookie |
POST 表单 | <form method="POST" action="…"> | 发送 Cookie | 不发送 |
iframe | <iframe src="…"></iframe> | 发送 Cookie | 不发送 |
AJAX | $.get(“…”) | 发送 Cookie | 不发送 |
Image | <img src="…"> | 发送 Cookie | 不发送 |
设置了 Strict 或 Lax 以后，基本就杜绝了 CSRF 攻击。当然，前提是用户浏览器支持 SameSite 属性。
None
浏览器会在同站请求、跨站请求下继续发送 cookies，不区分大小写。网站可以选择显式关闭 SameSite 属性，将其设为 None ，同时必须设置 Secure 属性（表示 Cookie 只能通过 HTTPS 协议发送，HTTP 协议不会发送），否则无效。
下面为无效响应头：
Set-Cookie: widget_session=abc123; SameSite=None
下面为有效响应头：
Set-Cookie: widget_session=abc123; SameSite=None; Secure
