上周五的時候，一個同事問我一個單點登錄的問題 。整個系統(tǒng)結(jié)構(gòu)并不復(fù)雜，在webapp應(yīng)用中配置一個sso應(yīng)用的servlet 過濾器 ，這個過濾器會從指定的域名下拿cookie中保存的一個加密sessionid ，利用這個sessionid到sso系統(tǒng)中判斷是否登錄以及是否在登錄有效期內(nèi)，未登錄則進入登錄頁面，登錄成功后，通過一個瀏覽器的302重定向進入目標(biāo)頁面。
同事反映，正常登錄以后進入的目標(biāo)頁面，地址不對，我看了一下， 是目標(biāo)主機的端口號丟失了。于是我在本地搭建了一個測試環(huán)境，啟動tomcat進行測試，發(fā)現(xiàn)并沒有出現(xiàn)類似的問題，debug到源碼發(fā)現(xiàn)目標(biāo)頁面URL也是正確的，繼續(xù)debug源碼，發(fā)現(xiàn)sso的servlet過濾器使用的是httpservletRequest獲取到http請求的hostname,port,requestURI的。
這時， 我又分析同事的maven 依賴的sso 二方包版本是否和我的一致， 也沒有問題。
?
進一步分析應(yīng)用部署環(huán)境的差異， 發(fā)現(xiàn)同事的環(huán)境使用了nginx + tomcat的架構(gòu)， 采用nginx做了一層負載均衡代理，于是查看webapp獲取到的requestURL，發(fā)現(xiàn)根本就沒有瀏覽器發(fā)送的原始URL中的端口。問題就在于此， 瀏覽器發(fā)送的請求是交給nginx，而nginx轉(zhuǎn)發(fā)請求給tomcat時，端口號已經(jīng)丟失掉了， 所以依賴于這個URL拼接出來的目標(biāo)頁面URL自然也就不對了。進一步看sso Filter 的配置項，是專門有針對主機端口的配置項的。?
?
這個問題的解決提醒我們，在查找問題時，系統(tǒng)部署環(huán)境的差異往往是解決問題的一個關(guān)鍵，特別是在很多問題從代碼本身找不到原因的時候。
?
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
