背景

1. 什么是三方cookie

如果浏览器存储的cookie的域（domain）和地址栏中的url属于同一网站，则认为这种cookie为一方cookie，否则为三方cookie。 以下面访问tmall主页为例，浏览器被种下的cookie中，域值为*.tmall.com的cookie为一方cookie（绿色），其他皆为三方cookie（红色）。

三方cookie通常用来用作用户行为追踪、单一登陆等作用。

当A网站通过某种形式访问了B网站的内容或资源（例如img，iframe）时往往会带来三方cookie。

通过三方cookie虽然能实现一些便捷功能（例如多域名登陆，天猫vs淘宝等）但是三方cookie的滥用也会带来诸如CSRF，个人信息泄露等安全问题或风险。

2. 在观远的应用场景里哪些地方用到了三方cookie

主要是两个场景

a) 观远系统以iframe的形式嵌入到客户的宿主系统中，此时观远为内容提供方，观远的cookie相对于宿主系统来说为三方cookie

b）观远自己系统中的iframe内容，例如iframe卡片，润乾填报等。此时润乾或iframe 卡片URL指向的网站为内容供应方，他们提供的cookie相对于观远来说是三方cookie

3. chrome 安全策略升级带来的影响

早期chrome并没有对三方cookie做任何安全管控。从56版本开始提供了一个cookie属性samesite，用来约束三方cookie的行为，并提供了三个选项：

• Strict: 仅限于同站请求
• Lax: 同站请求，或者跨站的GET的会导致页面URL发生变化的导航行为，包括链接、GET的Form提交。比如在 http://www.def.com 网站的页面中嵌入了一个链接 http://www.abc.com ，那么在用户点击此链接时发起的初始请求，会带上http://www.abc.com中设置为Lax的Cookie。而那些设置为Strict的Cookie是不会带上的。这种跨站链接还包括像嵌入到邮件中的链接。
• None: 没有限制，同站及跨站请求中都会带上，与传统的方式一样。

从76版本开始，chrome开始升级samesite的默认值，从none变为了Lax。其行为可归纳为：

所以对于2-a， 2-b中的场景，如果内容提供方没有配置更宽松的samesite安全等级（none），该cookie会被chrome过滤掉。对于2-a来说，我们的uIdToken存储在cookie中，前端无法获取uIdtoken会认为用户没有登录而转向登录页。目前赫基的部分客户端已经出现了问题。

4. 其他浏览器

• safari 已经完全禁止了三方cookie （待确认）
• FF，edge也会陆续follow chrome的行为。

根据Google官网准备逐步淘汰第三方 cookie说明，2024Q3开始逐步全面禁用第三方Cookie。

不过Google提供了替代方案：具有独立分区状态（CHIPS）的Cookie。

解决方案

根据前面相关问题的描述，我们认为可以提供以下方案给我们的用户

方案a：

1. 建议用户将观远和他们的业务系统部署在同一个域名下。这是最推荐的方式。
2. 建议个人用户修改自己的chrome浏览器配置，将安全等级降低。具体步骤如下：

1. Chrome打开 chrome://flags/
2. 搜索samesite,将三个搜索结果：SameSite by default cookies，Enable removing SameSite=None cookies，Cookies without SameSite must be secure均置为Disable
3. Relaunch Chrome浏览器即可。

3. 对于部署了HTTPS的客户，观远的前端可以通过构配置对应的cookie attributes保证服务可用。

方案b:

修改BI服务后端配置，降低BI服务的Cookie安全等级配置。

具体操作为：nginx https代理转发请求到guandata-web时增加如下配置

proxy_cookie_path / "/; HttpOnly; Secure; SameSite=None; Partitioned";