Cook Cookie, 我把 SameSite 給你燉爛了

什麼樣的知識，最好吃？入口即化的

github地址

囉裏吧嗦的開頭

SameSite cookie 推出已一年有餘，本身看了很多文章，也撞了很多南牆，因此仍是那句好記性不如爛筆頭。你可能以爲本身懂了，但試着講出來，才能知道本身是否真的懂了。

列一列本身看過的文章：

• 帶你入門的阮老師：https://www.ruanyifeng.com/bl...
• 很長很官方的文章：https://web.dev/samesite-cook...
• SameSite 誕生的草案：https://tools.ietf.org/html/d...
• SameSite 開始發威的草案：https://tools.ietf.org/html/d...
• RFC 6265 Cookie 規範，HTTP State Management Mechanism：https://tools.ietf.org/html/r...

走進SameSite

和新冠一塊兒火了的SameSite

SameSite Cookie行爲更新去年就開始被提上日程，2020年2月隨着Chrome 80的推出，這個屬性開始正式生效，但由於3月份正是全球新冠肆虐的時候，當時的維護者都還活在新冠的恐懼之下，網站無法及時更新，這項政策致使不少網站癱瘓，chrome官方又在4月進行了回滾，暫時終止了這項策略。直到2020年7月14日Chrome 84穩定版開始，從新恢復SameSite cookie策略，而且會逐步部署到Chrome 80以及以上的版本中。

若是你知道CSRF，那你就知道這項攻擊真正的核心就是利用 cookie 自動攜帶的行爲(進一步講就是跨站攜帶cookie)。

之因此會跨站攜帶，是由於起初 cookie 的規範中並無 SameSite 這個屬性；直到2016年first-party-cookies草案的推出，但並有多少人真正去用，而瀏覽器這邊的實現也默認是SameSite=None，因此對開發者並無什麼影響，天然就沒有引發多大的關注，至少不如此次，而提案初衷：改善安全和隱私泄露的問題。效果天然就不是很理想。

爲了解決這些問題，一個新的草案：Incrementally Better Cookies，在草案的開頭，就直接說道：

This document proposes two changes to cookies inspired by the properties of the HTTP State Tokens mechanism proposed in [I-D.west-http-state-tokens]. First, cookies should be treated as "SameSite=Lax" by default. Second, cookies that explicitly assert "SameSite=None" in order to enable cross-site delivery should also be marked as "Secure"

翻譯成中文就是兩個改進 ：

1. "SameSite=Lax" 變成默認設置，取代如今的"SameSite=None"；
2. 若是硬要設置成"SameSite=None"，則須要同時增長"Secure"標識，即這個cookie只能在Https連接上傳輸；

first-party-cookies 草案規定了什麼

草案那麼長，我就關（kan）注（dong）了一段話：

能夠簡單理解爲同站 和 跨站的定義，中文大白話翻譯就是：

1. 若是請求的url是空，則瀏覽器須要以domain爲請求的地址；好比 closertb.site 網站html有這樣一個<script src="/static/index.js"></script> 標籤，那最後瀏覽器發出的請求就是：closertb.site/static/index.js，這沒得說，確定是同站；
2. 若是請求domain 和 瀏覽器地址欄url匹配(注意是匹配，不是相等)，也是同站；
3. 除此之外，都是跨站；

好傢伙，感受說了和沒說同樣；而後定義了SameSite語義:

「 SameSite」限制了cookie的使用範圍，以便它 僅在這些請求是「相同站點」時附加到請求中， 由2.1節中的算法定義。例如，要求 對於「 https://example.com/sekrit-image」, 將附加相同站點的cookie 即當且僅當從其站點爲「example.com」。

但在接下來的幾節，並無出現Strict、Lax、None 這些語義，我猜主要仍是這只是一份草稿，還不涉及到具體實現。

在最新的RFC6265 替代草案draft-ietf-httpbis-rfc6265bis-05, 說起了這三個屬性值，並作了介紹，但貌似仍是落後如今瀏覽器的實現，由於草案中SameSite=None仍然是默認屬性；

SameSite 的屬性值及其區別

我以爲這部分再講就是蛋炒飯了，畢竟今年太多人講過了，沒啥意義。

你能夠看：阮一峯老師

但更推薦MDN官方的：SameSite cookies

你能夠經過：https://samesite-sandbox.glit... 網站來了解你的瀏覽器是否開啓Incrementally Better Cookies(IBC)

用實例說話，到底限制的是什麼？

直到如今，其實不少前端開發者對這個變化是無感的，主要兩個緣由：

• 鑑權token化，cookie更多充當存儲；
• 業務太簡單，cookie使用的場景都是同站的，因此新規並無多大影響，新規是針對跨站作cookie攜帶限制的；

同站的影響是不大的

大多數公司cookie都是用來作單點登陸身份鑑權的，這種多數存在同站；好比:

• 鑑權服務：sso.closertb.site
• erp服務：erp.closertb.site
• crm服務：crm.closertb.site
• 其餘服務：xxx.closertb.site

當用戶初次打開crm服務網站時，會首先調用鑑權服務查詢該用戶是否已受權或受權有效？若是無效，就會重定向到sso.closertb.site網站讓用戶登陸受權，受權完成後，服務會在closertb.site種下幾個cookie，用於識別用戶身份，而後就重定向回crm.closertb.site網站；當用戶再次打開crm服務或其餘同站網站時，也會先調用鑑權服務，因爲cookie還有效，因此用戶就不用再去登陸了，能夠繼續在網站瀏覽。

以上就是一個很是典型的單點登陸設計，都是利用瀏覽器在同站請求會自動攜帶cookie來作身份識別的方式；

跨站纔是重點

但還有一種稍微複雜的狀況，跨站單點登陸，舉個典型的例子：天貓和淘寶

這個狀況複雜就複雜在淘寶和天貓是跨站的，當淘寶登陸了時，你再去訪問天貓，會有一系列的鑑權操做：

但今天不是主講淘寶天貓的單點登陸設計，主要是講cookie，這裏有一個設計，就是跨站cookie的使用；在用戶登陸了淘寶後，用戶再去打開天貓，由於天貓淘寶是一套用戶體系，因此他們作了免登，就是截圖所示，先是調用了了top-tmm.taobao.com/login_api.do, 這個請求會攜帶*.taobao.com域下的cookie, 從而服務端就能知道這個用戶登陸過。因爲請求是在 tmall.com 站點下發出的，因此這是一個跨站請求，這也是此次新規重點照顧的場景。

爲了在新版本瀏覽器下，能繼續讓單點登陸有效，因此淘寶的開發也就作點改變來適應, cookie 都打上了samesite=None與secure標識, 利用改進第二條規則。

因爲Secure的限制，要攜帶的跨站點請求必須在帶有安全標識站點下發出請求

因此當你輸入http://tmall.com，站點302必會重定向到https://tmall.com 安全域名下。

除了上面這種故意設計的跨站，還有不少其餘形式，已經有高手總結過，我就發一個我我的以爲比較全的，來自知乎

對開發的影響

雖然咱們大多數開發開發的站點都是同站，但在本地調試時，基本都是在http://localhost:port站點下進行，要拿到登錄態，面臨的狀況都是跨站。因此爲了應對此次更新，通常有兩種方法來解決：修改安全限制 和 修改調試站點域名。

修改安全限制就像
關閉跨域限制同樣，只須要打開chrome://flag站點進行設置，以下圖所示：

上面那種改動粗暴，雖然有效，但不適合咱們文化人，文化人就得乾點文化人該乾的事，修改調試站點地址, 好比：

• 本地server 站點地址 localhost:8906 切換到local.closertb.site，通常來講都須要修改webpack host地址；
• 給local.closertb.site加本地解析，說人話，就是修改host解析
• 瀏覽器訪問，看看效果

一些前端要懂的服務端知識

同源 VS 同站 或 跨域 VS 跨站

同源，基本上懂行的前端都知道，只有請求的地址與站點是同協議、同域名、通端口，才能稱爲同源，除此之外，都是跨域；

而同站就沒這麼嚴格，簡單看看同站定義：只要兩個 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是跨站(注意是跨站)。

爲何a.github.io和b.github.io是跨站，由於 github.io 是有效頂級域名

再來些零碎的

1.雖然同站能夠攜帶cookie，但跨了域的同站請求不會主動攜帶，fetch須要設置credentials屬性爲include(ajax有類似設置), 但這只是開始，由於設置了這個屬性攜帶了cookie後，這個請求就變成了非簡單請求，服務端須要針對請求的站點設置Access-control-Allow-Credentials，如圖下；



2.服務端 set-cookie 也須要遵循同站規則，不然不生效；eg: 當前網站域名local.closertb.site, 登陸發送請求/user/login，但該請求向admin.closertb.site種了一個cookie, 這個玩法就是非法的（管太寬），這個請求僅可種domai爲'local.closertb.site' 或 'closertb.site';爲無效時，瀏覽器會標黃提醒

3.cookie 的path 是針對於請求地址的，和當時瀏覽器地址無關；path 經常使用於多個服務經過一個網關來給前端提供接口，爲儘可能區分各個服務的cookie，因此有這個path屬性設置，這樣能夠減小請求攜帶的cookie數量；圖下所示的cookie，就只會在請求地址是以/rule 開頭時才攜帶，其餘地址就會忽略；

4.ajax 和 fetch 請求，響應302, 是不能直接改變瀏覽器地址進行跳轉的，除非前端手動去操做；這就是爲何咱們會說ajax 和 fetch 是先後端分離的開始，由於之前不少jsp 或 php頁面，若是用戶沒有權限，就302重定向到登陸頁；而先後端分離後，更常見的作法是響應401，而後前端再手動跳轉到登陸頁；

打個廣告

阿里本地生活成都、杭州、上海三地招前端、測試、後端，有意的能夠發簡歷到我郵箱，也能夠加我微信諮詢。 微信號：5娃4娃5幺娃34.。。