Cookie理解

具体属性资料:https://github.com/mqyqingfeng/Blog/issues/157

起因:HTTP是无状态协议

注意:Cookie的存在是为了解决后端服务的状态问题,而不是通讯协议的状态问题,别搞混了。

优点:不需要保持状态,减少服务器的CPU及内存消耗。也正是因为HTTP协议本身非常简单,所以被应用于不同场景。

解决方案:Cookie

Cookie

作用:通过在请求和响应报文中写入Cookie信息来控制客户端的状态。

主要流程:Cookie会根据服务器端发送的响应报文内的Set-Cookie首部字段信息,通知客户端保存Cookie。当下次客户端再次发送请求,带上该Cookie;服务端根据客户端Cookie鉴定客户端来源,对比服务器记录,得到该客户端之前状态信息。


跨域和跨站

首先要理解的一点就是跨站和跨域是不同的。同站(same-site)/跨站(cross-site)」和第一方(first-party)/第三方(third-party)是等价的。但是与浏览器同源策略(SOP)中的「同源(same-origin)/跨域(cross-origin)」是完全不同的概念。

同源策略的同源是指两个 URL 的协议/主机名/端口一致。例如,https://www.taobao.com/pages/...,它的协议是 https,主机名是 www.taobao.com,端口是 443。

同源策略作为浏览器的安全基石,其「同源」判断是比较严格的,相对而言,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 是跨站(注意是跨站)。

主要注意点:SameSite

SameSite 是最近非常值得一提的内容,因为 2 月份发布的 Chrome80 版本中默认屏蔽了第三方的 Cookie,这会导致阿里系的很多应用都产生问题,为此还专门成立了问题小组,推动各 BU 进行改造。

属性值:
1. Strict:
仅允许一方请求携带Cookie,即浏览器将只发送相同站点请求的Cookie,即当前网页URL与请求目标URL完全一致。

2. Lax: 允许部分第三方请求携带Cookie

3. None: 无论是否跨站都会发送Cookie


影响:举个例子,例如阿里巴巴在各大网站比如今日头条、网易、微博等投放广告,是用iframe嵌入的,设置SameSite为Lax就不能发送Cookie,就不能准确的进行推荐。

解决:设置SameSite为None

不过也会有两点要注意的地方:

HTTP 接口不支持 SameSite=none

    如果你想加 SameSite=none 属性,那么该 Cookie 就必须同时加上 Secure 属性,表示只有在 HTTPS 协议下该 Cookie 才会被发送。

需要 UA 检测,部分浏览器不能加 SameSite=none

    IOS 12 的 Safari 以及老版本的一些 Chrome 会把 SameSite=none 识别成 SameSite=Strict,所以服务端必须在下发 Set-Cookie 响应头时进行 User-Agent 检测,对这些浏览器不下发 SameSite=none 属性

推荐阅读更多精彩内容