線程通訊的三種方法！通俗易懂
線程通信是指多個(gè)線程之間通過某種機(jī)制進(jìn)行協(xié)調(diào)和交互，例如，線程等待和通知機(jī)制就是線程通訊的主要手段之一。 在 Java 中，線程等待和通知的實(shí)現(xiàn)手段有以下幾種方式：Object 類下
一個(gè)公司內(nèi)部可能存在多個(gè)系統(tǒng)，如果每一個(gè)人在使用不同系統(tǒng)的時(shí)候都需要重新登錄，那么會做大量系統(tǒng)登錄切換、耗費(fèi)比較多的精力去管理賬號和密碼，那么有沒有辦法在一個(gè)公司內(nèi)部的所有系統(tǒng)只需要一次登錄驗(yàn)證，后續(xù)使用其他系統(tǒng)的時(shí)候不用重復(fù)登錄就可以直接使用呢，這就是單點(diǎn)登錄要解決的問題。
單點(diǎn)登錄英文全稱 Single Sign On（SSO），允許用戶一次登錄即可訪問多個(gè)應(yīng)用程序或系統(tǒng)，無需為每個(gè)應(yīng)用程序或系統(tǒng)分別輸入認(rèn)證憑據(jù)，便可在其他所有系統(tǒng)中得到授權(quán)，無需再次登錄。
在某一天我們登錄一個(gè)內(nèi)部系統(tǒng)時(shí)，突然出現(xiàn)了循環(huán)登錄問題，前端頁面不斷刷新，提示“重定向次數(shù)過多問題”。
打開前端調(diào)試功能, 我們會發(fā)現(xiàn)確實(shí)存在大量重定向請求的問題：
那么平時(shí)登錄沒問題的系統(tǒng)為什么突然間就循環(huán)登錄呢?并在頁面上提示的解決方法“嘗試刪除您的 Cookie 操作”，按照這個(gè)操作以后，確實(shí)系統(tǒng)又可以跳轉(zhuǎn)到登錄頁面正常進(jìn)行登錄了，這又是什么原因？下面我們將逐一分析。
上述是一個(gè)通用的系統(tǒng)權(quán)限管控和單點(diǎn)系統(tǒng)認(rèn)證的標(biāo)準(zhǔn)流程：
Connection: keep-aliveContent-Length: 0Date: Wed, 25 Oct 2023 08:29:43 GMTLocation: http://aaa.x.y/console/login/auth?redirectUrl=http://aaa.x.y/optrace: xx.xx.xx.xx:80/302 <- -Server: nginxSet-Cookie: token=fakdfajdfdjfdjkfaldfjk'afafjasfasfa; Max-Age=86400; Expires=Thu, 26-Oct-2023 08:29:43 GMT; Domain=x.y; Path=/; HttpOnly一個(gè)公司內(nèi)部一般情況下只有一個(gè)域名，通過二級域名區(qū)分不同的系統(tǒng)。比如我們有個(gè)域名叫做：x.y ，同時(shí)有兩個(gè)業(yè)務(wù)系統(tǒng)分別為：app1.x.y 和 app2.x.y。SSO 登錄以后，可以將 Cookie 的域設(shè)置為頂域，即 x.y ，這樣所有子域的系統(tǒng)都可以訪問到頂域的 Cookie ，實(shí)現(xiàn)單點(diǎn)登錄功能。
那么為什么會不斷循環(huán)登錄呢？
（1）從跳轉(zhuǎn)記錄來看，我們發(fā)現(xiàn)重新刷新頁面以后，重定向到了權(quán)限系統(tǒng)，并且 Request Headers 中的 Cookie 信息沒有傳對應(yīng)的 Token 信息。
（2）跳轉(zhuǎn)到權(quán)限系統(tǒng)過后，再跳轉(zhuǎn)到本系統(tǒng)的時(shí)候，已經(jīng)獲取到了對應(yīng)的 Token 信息，但是在 Set-Cookie 信息的時(shí)候，出現(xiàn)了一個(gè)警告。
警告的具體內(nèi)容為：
大致意思是：這次執(zhí)行 Set-Cookie 操作被阻止了，原因是這個(gè) Cookie 不是通過安全的連接進(jìn)行傳輸?shù)模覀冞@次訪問確實(shí)使用了 HTTP 進(jìn)行，本應(yīng)該通過設(shè)置 Secure 屬性來覆蓋對應(yīng)的 Cookie。
這里的 Secure 屬性是 Cookie 的一個(gè)屬性，Secure 屬性是說如果一個(gè) Cookie 被設(shè)置了 Secure = true，那么這個(gè) Cookie 只能用 HTTPS 協(xié)議發(fā)送給服務(wù)器，用 HTTP 協(xié)議是不發(fā)送的，而我們查看上面標(biāo)注位置的下一個(gè) Login 請求確實(shí)沒有傳 Cookie 信息，從而繼續(xù)進(jìn)行用戶是否登錄校驗(yàn)，進(jìn)入死循環(huán)過程， 可以看下面的示意圖:
我們可以看到循環(huán)登錄以后，會在瀏覽器頁面上提示 xxx.x.y 重定向次數(shù)過多，嘗試清除 Cookie 信息，那清除 Cookie 信息以后，是不是真的就可以解決這個(gè)問題呢，我們嘗試著清除瀏覽器緩存，確實(shí)可以解決這個(gè)問題，那清除瀏覽器緩存來解決循環(huán)登錄問題的底層原理是什么呢，其實(shí)質(zhì)就是將 Cookie 刪除，其他域名設(shè)置 Cookie 上的 Secure 屬性也就一并刪除了，從而使用 HTTP 域名進(jìn)入重新登錄流程，可以正常設(shè)置 Cookie 信息。
方法一：使用 HTTPS 的方式進(jìn)行訪問
現(xiàn)實(shí)使用中，我們無法控制其他 HTTPS 訪問的具有相同頂級域名的服務(wù)不去設(shè)置 Cookie 的 Secure 屬性，因而我們在后面使用的過程中還是會遇到這個(gè)問題，那么有沒有一種徹底的解決辦法能夠避免這個(gè)問題再次出現(xiàn)，我們前面已經(jīng)分析，之所以我們在開始使用 HTTP 能夠進(jìn)行正常訪問，然后突然間不能正常訪問了，就是因?yàn)橐呀?jīng)被 HTTPS 設(shè)置了的 Cookie 信息是無法被 HTTP 重新設(shè)置的，從而拿不到 Cookie 信息。那么就出現(xiàn)了第一種解決辦法，使用 HTTPS 的方式進(jìn)行訪問，即使其他服務(wù)設(shè)置了 Cookie 的 Secure 屬性，用 HTTPS 仍然能夠成功設(shè)置 Cookie 和獲取 Cookie。
方法二：在 Cookie 信息中新設(shè)置一個(gè) newToken
以上從 HTTP 轉(zhuǎn)為 HTTPS 訪問的方法在用戶主動找我們反饋時(shí)是能夠告訴它切換為 HTTPS 訪問的，但是如果對于一些沒有主動找我們反饋的用戶，其實(shí)是無法解決，可能喪失這個(gè)用戶造成用戶流失的情況，那么我們在用戶不進(jìn)行切換的情況下是否能夠解決這個(gè)問題。
同一個(gè)公司內(nèi)部接入的權(quán)限系統(tǒng)是一種底層公共能力，為了保證單點(diǎn)登錄，其實(shí)用戶信息的讀取都是通過同一個(gè) Cookie 參數(shù)（比如叫 Token ）讀取的，那么在其他域名設(shè)置了公共 Cookie 參數(shù)的 Secure 屬性而影響到 HTTP 登錄的時(shí)候，我們可以給服務(wù)新增加一個(gè) Cookie 參數(shù) newToken 去解決。
本文所闡述的問題，出現(xiàn)的背景是有兩個(gè)基本前提的：一是為了保證單點(diǎn)登錄，兩個(gè)域名屬于同一個(gè)頂級域名，權(quán)限系統(tǒng)中關(guān)于用戶信息的校驗(yàn)都是通過同一個(gè) Cookie 屬性去讀取的；第二個(gè)是 HTTPS 設(shè)置了頂級域名的 Cookie 信息的 Secure 屬性，然后使用 HTTP 訪問會導(dǎo)致循環(huán)登錄。有些開發(fā)者可能會有這樣一個(gè)疑問，那就是 HTTPS 我們一般開通的端口是 443 ， HTTP 我們一般開通的端口是 8080 ，為啥不從端口上進(jìn)行區(qū)分同一個(gè) Cookie 屬性從而避免干擾呢？
這個(gè)在 Cookie 規(guī)范（RFC 6265）中有所描述，那就是 Cookie 不提供通過端口進(jìn)行隔離的，也就是說如果一個(gè) Cookie 可以被一臺服務(wù)器上的運(yùn)行在某一個(gè)端口上的一個(gè)服務(wù)所讀取，那么也可以被這臺服務(wù)器上運(yùn)行在另外一個(gè)端口上的服務(wù)所讀取；如果一個(gè) Cookie 可以被一臺服務(wù)器上的運(yùn)行在某一個(gè)端口上的一個(gè)服務(wù)所寫入，那么也可以被這臺服務(wù)器上運(yùn)行在另外一個(gè)端口上的服務(wù)所寫入。
本文從實(shí)際開發(fā)過程中遇到的循環(huán)登錄問題入手，分析了由于設(shè)置 Secure 屬性導(dǎo)致使用 HTTP 訪問網(wǎng)頁無法保存 Cookie 信息從而導(dǎo)致循環(huán)登錄的根本原因，也給出了其他兩個(gè)解決此種問題的方案，對于其他開發(fā)人員解決權(quán)限系統(tǒng)循環(huán)登錄問題具有一定的借鑒意義。
參考資料：
單點(diǎn)登錄實(shí)現(xiàn)思路及方案
Sessions don't work in Chrome but do in IE
8.5. Weak Confidentiality
本文鏈接：http://www.tebozhan.com/showinfo-26-112767-0.htmlCookie的secure屬性引起循環(huán)登錄問題分析及解決方案
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號