上周五的時(shí)候，一個(gè)同事問我一個(gè)單點(diǎn)登錄的問題 。整個(gè)系統(tǒng)結(jié)構(gòu)并不復(fù)雜，在webapp應(yīng)用中配置一個(gè)sso應(yīng)用的servlet 過濾器 ，這個(gè)過濾器會(huì)從指定的域名下拿cookie中保存的一個(gè)加密sessionid ，利用這個(gè)sessionid到sso系統(tǒng)中判斷是否登錄以及是否在登錄有效期內(nèi)，未登錄則進(jìn)入登錄頁面，登錄成功后，通過一個(gè)瀏覽器的302重定向進(jìn)入目標(biāo)頁面。

同事反映，正常登錄以后進(jìn)入的目標(biāo)頁面，地址不對(duì)，我看了一下， 是目標(biāo)主機(jī)的端口號(hào)丟失了。于是我在本地搭建了一個(gè)測(cè)試環(huán)境，啟動(dòng)tomcat進(jìn)行測(cè)試，發(fā)現(xiàn)并沒有出現(xiàn)類似的問題，debug到源碼發(fā)現(xiàn)目標(biāo)頁面URL也是正確的，繼續(xù)debug源碼，發(fā)現(xiàn)sso的servlet過濾器使用的是httpservletRequest獲取到http請(qǐng)求的hostname,port,requestURI的。

這時(shí)， 我又分析同事的maven 依賴的sso 二方包版本是否和我的一致， 也沒有問題。

?

進(jìn)一步分析應(yīng)用部署環(huán)境的差異， 發(fā)現(xiàn)同事的環(huán)境使用了nginx + tomcat的架構(gòu)， 采用nginx做了一層負(fù)載均衡代理，于是查看webapp獲取到的requestURL，發(fā)現(xiàn)根本就沒有瀏覽器發(fā)送的原始URL中的端口。問題就在于此， 瀏覽器發(fā)送的請(qǐng)求是交給nginx，而nginx轉(zhuǎn)發(fā)請(qǐng)求給tomcat時(shí)，端口號(hào)已經(jīng)丟失掉了， 所以依賴于這個(gè)URL拼接出來的目標(biāo)頁面URL自然也就不對(duì)了。進(jìn)一步看sso Filter 的配置項(xiàng)，是專門有針對(duì)主機(jī)端口的配置項(xiàng)的。?

?

這個(gè)問題的解決提醒我們，在查找問題時(shí)，系統(tǒng)部署環(huán)境的差異往往是解決問題的一個(gè)關(guān)鍵，特別是在很多問題從代碼本身找不到原因的時(shí)候。

?

一個(gè)單點(diǎn)登錄問題的解決