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

現(xiàn)象

經(jīng)過測試， 出現(xiàn)單點(diǎn)登陸故障的是搜狗、360等雙核瀏覽器(默認(rèn)使用Chrome內(nèi)核)， 較新式的Edge、Chrome、Firefox均未出現(xiàn)此障礙。

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

拿出網(wǎng)絡(luò)分析利器Fiddler

循環(huán)重定向？

顯示單點(diǎn)登錄從website1?ticket =XXOO重定向回首頁website.com，確實(shí)發(fā)生了循環(huán)重定向，搜狗瀏覽器有重定向次數(shù)限制，最終返回瀏覽器定制的404 頁面。

結(jié)合之前手撕公司單點(diǎn)登錄原理:

探究站點(diǎn)發(fā)生循環(huán)重定向的原因：

自⑥ website1向?yàn)g覽器寫入Cookie for website1，重定向請求站點(diǎn)主頁www.website1.com⑦的時(shí)候，丟失Cookie for website1，導(dǎo)致website1認(rèn)為用戶未登陸，被迫重定向請求sso-website.com?service=http://www.website1.com②重新認(rèn)證；

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

定位問題

熟稔web開發(fā)的都知道 Cookie for website1 會(huì)在請求 website1.com時(shí)自然攜帶

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

故障關(guān)鍵在單點(diǎn)登錄最后一步重定向，竟然未攜帶Cookie for website1?

截圖：

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

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

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

最后在官方站點(diǎn)找到如下內(nèi)容：

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草案的瀏覽器不認(rèn)識Samesite= None屬性值，會(huì)遇到兼容性問題，若站點(diǎn)打算支持這些舊內(nèi)核瀏覽器須實(shí)現(xiàn)瀏覽器嗅探。

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

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內(nèi)核版本65，位列不兼容列表，binggo， 問題定位。

修復(fù)策略

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

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默認(rèn)將Cookie SameSite設(shè)為Lax, 遇到身份驗(yàn)證問題后，大多數(shù)SameSite使用被禁用。
IETF 2019標(biāo)準(zhǔn)發(fā)布了修復(fù)補(bǔ)丁，2019 SameSite草案規(guī)定：

• 與2016年草案不向后兼容

• 默認(rèn)將Cookie SameSite= Lax

• 顯式設(shè)置SameSite=None時(shí)，必須將該Cookie標(biāo)記為Secure,?None是一個(gè)新值

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

• 預(yù)定于2020年2月由Chrome默認(rèn)啟用該草案，瀏覽器需要遷移至該草案。

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

[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

▼

往期精彩回顧

▼

手撕公司單點(diǎn)登錄原理

ASP.NETCore跨平臺(tái)技術(shù)內(nèi)幕

ASP.NETCore結(jié)合Redis實(shí)踐消息隊(duì)列

轉(zhuǎn)載是一種動(dòng)力，分享是一種美德? ??~~..~~

如果你覺得文章還不賴，您的鼓勵(lì)是原創(chuàng)干貨作者的最大動(dòng)力，讓我們一起激濁揚(yáng)清。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。