昨天加班被一個問題困住了好久

問題描述

與同事調cas登錄，用的方式為使用iframe訪問后臺一個接口，為了讓iframe自動跳轉到cas最終帶回cookie，這樣后邊的接口都可以帶著cookie進行訪問了。但問題是我機器一直在頁面和cas登錄頁面來回跳，但我同事的機器沒有問題。

問題定位

我的機器是chrome92，我同事的機器是chrome64，通過對比兩個人的網絡請求參數發現，我的iframe請求跳轉到cas登錄頁面沒有帶著cookie信息，而我同事的帶著cookie信息

問題解決

現在知道是什么原因導致的了，現在來處理一下。通過網絡查詢，chrome 78~91之間的版本可以通過將SameSite by default cookies、Cookies without SameSite must be secure（chrome://flags/）這兩項設置為disable來解決。恰巧我的版本是92，網有說可以通過在快捷方式上增加--disable-features=SameSiteByDefaultCookies參數來解決。親試成功了！！！

原因

應用網友[https://juejin.cn/post/6844904088774115341]的描述：

Cookie 的SameSite屬性用來限制第三方 Cookie，從而減少安全風險。它可以設置三個值：

Strict

Strict最為嚴格，完全禁止第三方 Cookie，跨站點時，任何情況下都不會發送 Cookie。換言之，只有當前網頁的 URL 與請求目標一致，才會帶上 Cookie。
Set-Cookie: CookieName=CookieValue; SameSite=Strict;
復制代碼這個規則過于嚴格，可能造成非常不好的用戶體驗。比如，當前網頁有一個 GitHub 鏈接，用戶點擊跳轉就不會帶有 GitHub 的 Cookie，跳轉過去總是未登陸狀態。

Lax

Lax規則稍稍放寬，大多數情況也是不發送第三方 Cookie，但是導航到目標網址的 Get 請求除外。
Set-Cookie: CookieName=CookieValue; SameSite=Lax;
復制代碼設置了Strict或Lax以后，基本就杜絕了 CSRF 攻擊。當然，前提是用戶瀏覽器支持 SameSite 屬性。

None

網站可以選擇顯式關閉SameSite屬性，將其設為None。不過，前提是必須同時設置Secure屬性（Cookie 只能通過 HTTPS 協議發送），否則無效。
Set-Cookie: widget_session=abc123; SameSite=None; Secure

chrome升級到80版本之后(準確的說是78版本之后)，cookie的SameSite屬性默認值由None變為Lax，這個才是本次事件的根本原因。

參考資料：
Chrome瀏覽器版本升級帶來的跨域訪問問題
chrome瀏覽器92版本SameSite by default cookies被移除后的解決方案，Chrome中跨域請求無法攜帶Cookie的解決方案