項目中需要和第三方平台接口,加了來源IP鑒權功能,測試時發現沒有問題,但是部署以後發現存在問題,一直鑒權不通過,一群人抓瞎。
我找到那塊的代碼,跟了一遍流程發現邏輯沒有啥問題,但是最終的結果卻還是鑒權不通過,實在有些詭異。其基本邏輯為先取得配置的IP清單,然後通過request.getRemoteAddr()取得用戶端的IP位址,做鑒權和校驗,邏輯沒問題,那麼肯定是request.getRemoteAddr()出了問題,google下,發現有人遇到類似的問題。
最終定位為request.getRemoteAddr()這種方法在大部分情況下都是有效的。但是在通過了Apache,Squid等反向代理軟體就不能擷取到用戶端的真實IP位址了。
經過代理以後,由于在用戶端和服務之間增加了中間層,是以伺服器無法直接拿到用戶端的IP,伺服器端應用也無法直接通過轉發請求的位址傳回給用戶端。但是在轉發請求的HTTP頭資訊中,增加了X-FORWARDED-FOR資訊用以跟蹤原有的用戶端IP位址和原來用戶端請求的伺服器位址。
原來如此,我們的項目中正好是有前置apache,将一些請求轉發給後端的weblogic,看來就是這樣導緻的咯。
給出一份還算靠譜的代碼,如下:
Java代碼
public String getIpAddr(HttpServletRequest request) {
String ip = request.getHeader("x-forwarded-for");
if(ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
ip = request.getHeader("Proxy-Client-IP");
}
ip = request.getHeader("WL-Proxy-Client-IP");
}
if(ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
ip = request.getRemoteAddr();
return ip;
}
如果有人遇到類似問題,請多加留意,呵呵。
PS:可是,如果通過了多級反向代理的話,X-Forwarded-For的值并不止一個,而是一串ip值,究竟哪個才是真正的使用者端的真實IP呢?
答案是取X-Forwarded-For中第一個非unknown的有效IP字元串。如:X-Forwarded-For:192.168.1.110, 192.168.1.120, 192.168.1.130, 192.168.1.100,使用者真實IP為: 192.168.1.110
本文轉自 tony_action 51CTO部落格,原文連結:http://blog.51cto.com/tonyaction/429049,如需轉載請自行聯系原作者