上周五的時候，一個同事問我一個單點登錄的問題 。整個系統結構並不復雜，在webapp應用中配置一個sso應用的servlet 過濾器 ，這個過濾器會從指定的域名下拿cookie中保存的一個加密sessionid ，利用這個sessionid到sso系統中判斷是否登錄以及是否在登錄有效期內，未登錄則進入登錄頁面，登錄成功后，通過一個瀏覽器的302重定向進入目標頁面。
同事反映，正常登錄以后進入的目標頁面，地址不對，我看了一下， 是目標主機的端口號丟失了。於是我在本地搭建了一個測試環境，啟動tomcat進行測試，發現並沒有出現類似的問題，debug到源碼發現目標頁面URL也是正確的，繼續debug源碼，發現sso的servlet過濾器使用的是httpservletRequest獲取到http請求的hostname,port,requestURI的。
這時， 我又分析同事的maven 依賴的sso 二方包版本是否和我的一致， 也沒有問題。
進一步分析應用部署環境的差異， 發現同事的環境使用了nginx + tomcat的架構， 采用nginx做了一層負載均衡代理，於是查看webapp獲取到的requestURL，發現根本就沒有瀏覽器發送的原始URL中的端口。問題就在於此， 瀏覽器發送的請求是交給nginx，而nginx轉發請求給tomcat時，端口號已經丟失掉了， 所以依賴於這個URL拼接出來的目標頁面URL自然也就不對了。進一步看sso Filter 的配置項，是專門有針對主機端口的配置項的。
這個問題的解決提醒我們，在查找問題時，系統部署環境的差異往往是解決問題的一個關鍵，特別是在很多問題從代碼本身找不到原因的時候。