概念cookie: 服务端返回请求的时候会通过set-cookie在客户端设置cooie信息，客服端再次请求接口的时候会在头部带回去进行信息验证。
背景：系统A嵌套系统B，调用的时候会出现登录一直失败的问题。
问题：嵌套系统B的权限校验是通过头部的cookie字段信息去判断的，由于谷歌51开始禁止设置第三方网站导致请求头不能携cookie，以致于导致用户权限校验一直失败
典型案例：
A网站SameSite.a.com 作为iframe嵌入在B网站test.b.com 中 。B站中访问iframe（A站）时想要发起请求setCookie，但是cookie并没有被塞进去。以登陆信息举例，大多数系统在用户访问时如果登陆信息校验失败，就会发起登陆请求，登陆请求setCookie的同时又会重定向到系统，页面可能就会反复跳转刷新，进入死循环。
解决方案： 1. 两者部署到统一域名下，不同端口号
2. 存储系统A的cookie到系统B
知识点： 1.cookie的设置和获取 详情：developer.mozilla.org/zh-CN/docs/…
举个例子：** **cookie设置 cookie可以直接通过document.cookie=key=value;Domain=xx;Path=xx;设置，设置成功后可以通过document.cookie进行获取；或者直接在浏览器端进行查看
设置cookie
//localhost:5555 document.cookie = 测试token=测试内容;; |
|---|
默认path的值是当前页面的路径，可进行自定义设置** **** cookie的获取 domain的相同的时候，或者是属于他的子区域的，并且path是cookie的子目录的才可以获取 因为localhost:5556的path和locahost:5555Path不一样且不是localhost:5555的子目录所以获取不到’测试token‘ ![]()
**
同一domain下，Path=/可访问
设置cookie
//localhost:5555 ，设置Path=/document.cookie = 测试token=测试内容; Path=/; |
|---|
2.请求头自带cookie字段****
·
浏览器端某个 Cookie 的 domain（.a.com） 字段等于请求的域名或者是请求的父域名，请求的域名需要是 a.com/b.a.com 才可以
·
·
都是 http 或者 https，或者不同的情况下 Secure 属性为 false（即 secure 是 true 的情况下，只有 https 请求才能携带这个 cookie）
·
·
要发送请求的路径，跟浏览器端 Cookie 的 path 属性必须一致，或者是浏览器端 Cookie 的 path 的子目录，比如浏览器端 Cookie 的 path 为 /test，那么请求的路径必须为/test 或者/test/xxxx 等子目录才可以
·
上面 3 个条件必须同时满足，否则该请求就不能自动带上浏览器端已存在的 Cookie
localhost:5555
3.请求头自带origin****
有时候服务端会对origin进行判断是否可访问
跨域请求
除了get，head以外的同源请求
4.禁止第三方网站携带cookie****
跨域和跨站的区别：****
· 首先要理解的一点就是跨站和跨域是不同的。
· 同站(same-site)/跨站(cross-site)」和第一方(first-party)/第三方(third-party)是等价的。
· 但是与浏览器同源策略（SOP）中的「同源(same-origin)/跨域(cross-origin)」是完全不同的概念。
同源策略的同源，是指两个 URL 的“协议+主机名+端口”3者都一致。例如，www.taobao.com/pages/...，它的协议是 https，主机名是www.taobao.com，端口是 443，另一个url的这3者与之都一致才能叫“同源”。
同源策略作为浏览器的安全基石，其“同源”判断是比较严格的，而相对而言，Cookie中的“同站”判断就比较宽松：
只要两个 URL 的 eTLD+1 相同即可，不需要考虑协议和端口。 其中，eTLD 表示有效顶级域名，注册于 Mozilla 维护的公共后缀列表（Public Suffix List）中，例如，.com、.co、.uk、.github.io 等。而 eTLD+1 则表示，有效顶级域名+二级域名，例如taobao.com等。
举几个例子，www.taobao.com和www.baidu.com是跨站，www.a.taobao.com和www.b.taobao.com是同站，a.github.io和b.github.io是跨站(注意是跨站)。
chorme的SameSite属性:****
Chrome 51 开始，浏览器的 Cookie 新增加了一个SameSite属性，用来防止 CSRF 攻击和用户追踪。
Cookie 的 SameSite属性是用于设置Cookie的访问范围的
它可以设置三个值。
·
Strict
·
Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。
·
Set-Cookie: CookieName=CookieValue; SameSite=Lax;
·
这个规则过于严格，可能造成非常不好的用户体验。比如，当前网页有一个 GitHub 链接，用户点击跳转就不会带有 GitHub 的 Cookie，跳转过去总是未登陆状态。
·
·
Lax Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。
·
Set-Cookie: CookieName=CookieValue; SameSite=Lax;
·
设置了Strict或Lax以后，基本就杜绝了 CSRF 攻击。当然，前提是用户浏览器支持 SameSite 属性。
·
·
None
·
Chrome 计划将Lax变为默认设置。这时，网站可以选择显式关闭SameSite属性，将其设为None。不过，前提是必须同时设置Secure属性 （Cookie 只能通过 HTTPS 协议发送） ，否则无效。 下面的设置无效。
·
Set-Cookie: widget_session=abc123; SameSite=None
·
下面的设置有效
·
Set-Cookie: widget_session=abc123; SameSite=None; Secure
·
第三方cookie：****
第三方cookie是指非访问站点所生产的cookie，可能在访问的过程中加载了第三方的跟踪代码，资源，由第三方站点生产的cookie，比如你访问www.ichdata.com，同时加载百度上的资源，生成一个主域是baidu.com的cookie，这个就是第三方广告Cookie。
在 iframe 中，即使 iframe 页面和 iframe 的服务器不存在跨域问题，但是当 iframe 发出请求时，iframe 的父级页面也就是当前网页的 URL 和请求目标并不同源，所以请求想要携带的 iframe 域下的 cookie 属于第三方 cookie，浏览器默认会禁止其携带。
