臨近年關，咨詢師提出360、搜狗急速瀏覽器無法單點登錄到公司核心產品WD: 重定向過多。

現象

經過測試， 出現單點登陸故障的是搜狗、360等雙核瀏覽器(默認使用Chrome內核)， 較新式的Edge、Chrome、Firefox均未出現此障礙。

Developer tool監測不到原始的SSO請求，互聯網上同類型問題不少，答案卻慘不忍睹，味同嚼蠟，人云亦云。年末不能晚節不保，決心啃下硬骨頭.

拿出網絡分析利器Fiddler

循環重定向？

顯示單點登錄從website1?ticket =XXOO重定向回首頁website.com，確實發生了循環重定向，搜狗瀏覽器有重定向次數限制，最終返回瀏覽器定制的404 頁面。

結合之前手撕公司單點登錄原理:

探究站點發生循環重定向的原因：

自⑥ website1向瀏覽器寫入Cookie for website1，重定向請求站點主頁www.website1.com⑦的時候，丟失Cookie for website1，導致website1認為用戶未登陸，被迫重定向請求sso-website.com?service=http://www.website1.com②重新認證；

而sso-website.com站點檢測到存在Cookie for sso(該用戶已經認證)，又開始走④⑤⑥⑦步驟，在第⑦步依舊未攜帶Cookie for website1，又再次重定向請求sso-website.com?service=http://www.website1.com②，循環往復。

定位問題

熟稔web開發的都知道 Cookie for website1 會在請求 website1.com時自然攜帶

Set-Cookie: X-Gridsum-FullTicketId=TGT-178876-em4uf0faD1c4pbt*********k5Z0vN4uPOoEBWfGIP6l-x-gridsumdissector; path=/; samesite=none; httponly

故障關鍵在單點登錄最后一步重定向，竟然未攜帶Cookie for website1?

截圖：

著重分析寫入Cookie for website1的附加屬性:

Path 指示需要發送該cookie頭的根url, =/ 表示站點下所有地址都會發送該Cookie SameSite 設置該Cookie的同源策略， = none 指示客戶端禁用Cookie的同源限制 HttpOnly 指示創建的Cookie是否能通過Javascript訪問(該cookie依然存于瀏覽器上)，這里true，表示不能通過Javascript訪問該Cookie

從屬性定義看，屬性值的寫法也無懈可擊。

最后在官方站點找到如下內容：

The SameSite = None parameter causes compatibility problems with clients that implemented the prior 2016 draft standard (for example, iOS 12). See Supporting older browsers in this document; Apps accessed from older browsers which support the 2016 SameSite standard may break when they get a SameSite property with a value of None. Web apps must implement browser detection if they intend to support older browsers
遵守IETF 2016草案的瀏覽器不認識Samesite= None屬性值，會遇到兼容性問題，若站點打算支持這些舊內核瀏覽器須實現瀏覽器嗅探。

這個信息讓我眼前一亮，趕緊對比故障的瀏覽器內核：

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3314.0 Safari/537.36 SE 2.X MetaSr 1.0

搜狗瀏覽器Chrome內核版本65，位列不兼容列表，binggo， 問題定位。

修復策略

我們的目的是為兼容這些舊核心瀏覽器，但是本人不打算打補丁(瀏覽器嗅探，根據User-Agent屏蔽SameSite=none)，
結合站點的同源限制的現狀，本站點沒有必要顯式設置SameSite= None，可保持SameSite默認值Lax。
說干就干，修改SameSite屬性值為Lax，重新k8s部署之后，搜狗瀏覽器正常單點登陸。

context.Response.Cookies.Append(_options.SsoTgtName, tgt1, new Microsoft.AspNetCore.Http.CookieOptions{HttpOnly = true,SameSite = Microsoft.AspNetCore.Http.SameSiteMode.Lax,Secure = false,});

SameSite歷史和版本變更

ASP.NET Core是在2.0版本開始支持SameSite(IETF 2016草案)，ASP.NET Core默認將Cookie SameSite設為Lax, 遇到身份驗證問題后，大多數SameSite使用被禁用。
IETF 2019標準發布了修復補丁，2019 SameSite草案規定：

• 與2016年草案不向后兼容

• 默認將Cookie SameSite= Lax

• 顯式設置SameSite=None時，必須將該Cookie標記為Secure,?None是一個新值

• ASP.NET Core 3.1在SameSite枚舉值新增Unspecified，表示不寫入SameSite屬性值，繼承瀏覽器默認的Cookie策略

• 預定于2020年2月由Chrome默認啟用該草案，瀏覽器需要遷移至該草案。

綜上，SameSite=None引出了一個難纏的瀏覽器新舊版本兼容問題，就本站而言, Cookie的同源策略SameSite=Lax是可行的，是能夠適應大多數單點登錄。?

[1] https://docs.microsoft.com/en-us/aspnet/core/security/samesite?view=aspnetcore-2.1
[2] https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core

▼

往期精彩回顧

▼

手撕公司單點登錄原理

ASP.NETCore跨平臺技術內幕

ASP.NETCore結合Redis實踐消息隊列

轉載是一種動力，分享是一種美德? ??~~..~~

如果你覺得文章還不賴，您的鼓勵是原創干貨作者的最大動力，讓我們一起激濁揚清。

總結

以上是生活随笔為你收集整理的临近年关，修复ASP.NET Core因浏览器内核版本引发的单点登录故障的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。