Java: request. getremoteaddr ()

 

In JSP, you can obtain the Client IP Address:Request. getremoteaddr ()
In most cases, this method is effective. However, the real IP address of the client cannot be obtained through reverse proxy software such as Apache and squid.

If the reverse proxy software is used, set http: // 192.168.1.110: 2046/

The URL reverse proxy for http://www.xxx.com/
When usingRequest. getremoteaddr ()
The obtained IP address is 127.0.0.1 or 192.168.1.110.

Instead of the client's real IP address.

After the proxy, because the intermediate layer is added between the client and the service, the server cannot directly obtain the Client IP address, and the server application cannot directly return the request address to the customer.
. However, X-FORWARDED-FOR information is added in the HTTP header information that forwards the request. It is used to track the original Client IP address and the server address of the original client request. When we
Http://www.xxx.com/index.jsp/ access
Instead of accessing the index. jsp file on the server, the browser first accesses http: // 192.168.1.110: 2046/index. jsp.
The proxy server returns the access result to our browser. Because the proxy server accesses index. jspRequest. getremoteaddr ()
The obtained IP address is actually the proxy server address, not the client IP address.

So we can obtain the real IP address of the client. Method 1:

Public String getremortip (httpservletrequest request ){
If (request. getheader ("X-forwarded-for") = NULL ){
Return request. getremoteaddr ();
}
Return request. getheader ("X-forwarded-");

}

But when I access http://www.xxx.com/index.jsp/
The returned IP address is always unknown, and it is not 127.0.0.1 or 192.168.1.110 as shown above.

And I access http: // 192.168.1.110: 2046/index. jsp
The real IP address of the client can be returned, and a method is written for verification. The reason is squid. The preparation file forwarded_for squid. conf
The item is on by default. If forwarded_for is set to off, the value is X-forwarded-for: unknown.

So we can obtain the real IP address of the client. Method 2:

1 Public String getipaddr (httpservletrequest request ){
2 string IP = request. getheader ("X-forwarded-");
3 if (IP = NULL | IP. Length () = 0 | "unknown". equalsignorecase (IP )){
4 IP = request. getheader ("proxy-client-IP ");
5}
6 if (IP = NULL | IP. Length () = 0 | "unknown". equalsignorecase (IP )){
7 IP = request. getheader ("wl-proxy-client-IP ");
8}
9 If (IP = NULL | IP. Length () = 0 | "unknown". equalsignorecase (IP )){
10 IP = request. getremoteaddr ();
11}
12 Return IP;
13}

However, if a multi-level reverse proxy is passed, there will be more than one X-forwarded-for value, but a string of IP values. Which is the real IP address of the client?

The answer is to take the first valid IP string not unknown in X-forwarded-.

For example:
X-forwarded-for: 192.168.1.110, 192.168.1.120, 192.168.1.130, 192.168.1.100
The user's real IP address is 192.168.1.110.
Note: This method is not necessarily 100% accurate. Many people on the internet mentioned that to be accurate, a client space, such as applet, must be created.

(0

The source IP address authentication function needs to be added to the interface of the project and a third-party platform. No problems are found during the test. However, problems are found after deployment, and authentication fails all the time.

I found the code and followed the process to find that the logic was correct, but the final result still failed authentication. It was a bit strange. The basic logic is to obtain the configured IP list first, and thenRequest. getremoteaddr ()
There is no logic problem in obtaining the client's IP address for authentication and verification, so it must be because of a problem with request. getremoteaddr (). Google found that someone encountered a similar problem.

The final positioning is request. getremoteaddr (), which is effective in most cases. However, the real IP address of the client cannot be obtained through reverse proxy software such as Apache and squid.

If the reverse proxy software is used, set http: // 192.168.1.110: 2046/

The URL reverse proxy for http://www.xxx.com/
When usingRequest. getremoteaddr ()
The obtained IP address is 127.0.0.1 or 192.168.1.110.

Instead of the client's real IP address.

After proxy, because the intermediate layer is added between the client and the service, the server cannot directly obtain the IP address of the client, and the server application cannot directly return the IP address of the forwarded request to the client. However, in the HTTP header information of the forwarded requestX-FORWARDED-FOR

Information is used to track the original Client IP address and the server address of the original client request.
In the past, we had a good project with a front-end Apache and forwarded some requests to the backend WebLogic, which seems to be the result of this.

A fairly reliable code is provided as follows:

 

Java code

1. Public
   String getipaddr (httpservletrequest request ){
   
2. String IP = request. getheader ("X-forwarded-"
   );
   
3. If
   (IP = NULL
   | IP. Length () = 0
   | "Unknown"
   . Equalsignorecase (IP )){
   
4. IP = request. getheader ("proxy-client-IP"
   );
   
5. }
   
6. If
   (IP = NULL
   | IP. Length () = 0
   | "Unknown"
   . Equalsignorecase (IP )){
   
7. IP = request. getheader ("wl-proxy-client-IP"
   );
   
8. }
   
9. If
   (IP = NULL
   | IP. Length () = 0
   | "Unknown"
   . Equalsignorecase (IP )){
   
10. IP = request. getremoteaddr ();
    
11. }
    
12. Return
    IP address;
    
13. }
    

If someone encounters a similar problem, please pay more attention to it.

 

PS: however, if multi-level reverse proxy is adopted, there will be more than one X-forwarded-for value, but a string of IP values. Which is the real IP address of the client?
The answer is to take the first valid IP string not unknown in X-forwarded-. For example, X-forwarded-for: 192.168.1.110,
192.168.1.120, 192.168.1.130, 192.168.1.100. the user's real IP address is 192.168.1.110.