chrome samesite引起的烏龍事件

事發：

今天調試一個好久沒改過的頁面（需登陸），出現：登陸成功後又跳到了登陸頁的狀況。百思不得其解。

緣由：

排查了好久，猜想和samesite有關。個人chrome是80版本,其有個新特性：限制第三方 Cookie發送。登陸成功後，重定向到目標頁面video.m.abc.com，再次驗證登陸時，沒法發送cookie到驗證服務login.m.abc.com。

理一理：

1. cookie的發送問題：

• 當在login.m.abc.com登陸成功後，會種下cookie。驗證登陸時，請求會帶上login.m.abc.com下全部cookie，包括以如下方式設置的：

Set-Cookie:name=xiaoming; // 只可在login.m.abc.com下獲取
Set-Cookie:name=xiaoming;Domain=.m.abc.com; // 可在.m.abc.com及其子域下獲取。
複製代碼

2. samesite的限制： 在form表單，img標籤上發送跨域請求，容易形成csrf攻擊。samesite就是爲了防止這種狀況。經過響應設置，分爲如下狀況：

Set-Cookie: CookieName=CookieValue; SameSite=Strict; // 相關資料名曰：url必須一致
Set-Cookie: CookieName=CookieValue; SameSite=Lax;  // 只在a標籤，link預加載和get表單才能攜帶cookie
Set-Cookie: widget_session=abc123; SameSite=None; Secure // 不限制，但須要https傳輸
複製代碼

3. 瀏覽器的samesite和響應設置的samesite有啥關係？ 上面一點是從站點自己出發的，但做爲一個瀏覽器的用戶，我確定但願越安全越好，並且本身有必定的控制權。 地址欄輸入chrome://flags

• 若是啓用第一條，將未指定SameSite屬性的cookie視爲SameSite=Lax。
• 在第一條啓用的前提下，啓用第二條，會更加嚴格的要求傳輸必須爲https。

4. 結果：

• 嘗試解決：想要和以前同樣，跨域時帶上cookie，必需要服務端的配合。samesite設置爲none，且在https下傳輸。查看cookie後，已經有none屬性，問題可能存在https。
• 烏龍的緣由：所謂的限制發送cookie，是在跨站原則上的，不一樣於cros，www.taobao.com 和 www.baidu.com 是跨站，www.a.taobao.com 和 www.b.taobao.com 是同站，後者不會有samesite的影響。
• 持之以恆：我發如今chrome的模擬手機的調試時，沒有登陸問題，因此我猜想。此次烏龍事件和samesite無關，taobao 2月對服務進行改造的時候順便判斷了user-agent，若是是pc模式就沒法登陸。