I am using nginx with tomcat - serving requests.
I wanted to log real client Ip address at tomcat log instead of ip of machine where nginx is configured.
I've been done with it by setting X-Real-IP and X-Forwarded-For header at nginx and by using RemoteIpValve at tomcat.
It works fine and showing me real client ip address at logs.
I need real ip address to be shown at tomcat --> server status under the section where request list is shown which are being served specified with different stage value.
At this place, I'm getting ip address of machine where nginx is configured.
Instead, I need real client ip address to be shown.
Which one of my "real" IP addresses do you want to receive? The one that my machine lives at on the LAN? The one that all machines making requests that are routed via my high-speed link present? Or the one that all machines making requests via my low-speed business link show up under?
IP addresses are not trustworthy user identifiers. They're not even all that dependable as geographic locators. The service that the JavaRanch uses says I live 20 miles nearer the ocean than I actually do.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Oct 01, 2012
Thanks for replying.
I know Ip addresses are not such trustworthy but It's a requirement to have it at my place.
Below is the example explaining what I'm really looking for:
user ---> send request to ---> my server
When people demand unrealistic things where I work, I consider it a requirement to keep an up-to-date CV.
My "real" IP address is (currently) 192.168.10.6. So is the IP address of countless thousands - perhaps millions of other people across the planet, because it's in one of the designated Private IP address groups which, unlike the public addresses are not required to be unique. I may or may not have that same IP address tomorrow, since it was dynamically assigned to me via DHCP.
The address that an external server such as yours would see is usually 188.8.131.52. That is also the address that comes in for every other laptop, desktop, tablet, webcam (when available) and WiFi cell phone user in the mousetech.com domain. In other words, as a unique userID, it's worse than useless, just like the DHCP-assigned IP address is.
In the case where the client has a unique (public) IP address, but it's being obscured by an intermediary (proxy) mechanism, the only way you're going to be able to obtain the original address is is the proxy co-operates and adds it as a special information packet with that info in it. A lot of such proxies are designed to do the exact opposite in order to make their end-users more anonymous, not less so.
Joined: Oct 01, 2012
I have confirmed at my work place with our all discussed points and found that this is being implemented for intranet only.
our actually interest is in getting real ip of LAN user requesting.
how can i achieve :
user(ip:192.168.0.32) ------------> nginx (ip: 192.168.0.33) -----> tomcat
tomcat server status(displaying serving requests with the stage information)-
should display 192.168.0.32 as client IP whose request is being served by tomcat. (currently clientIP showing 192.168.0.33 ip)
As I said, without co-operation, you cannot know the original IP address of the client once it has passed through an intermediary unless that intermediary wishes to be helpful about it.
Apache's mod_proxy component, operating in reverse proxy mode adds a set of headers to the HTTP request stream (in other word's, it's being helpful about it). The one with the proxy's remote client IP address is "X-Forwarded-For". If you make the Tomcat webapp dump incoming HTTP Request headers, look for it (or something similar), as nginx considers itself comparable to Apache as a reverse proxy.
The "forwarded-for" IP address isn't guaranteed to be one of the true IP addresses of the client system, since other factors can be involved. For example, a VM guest's IP address is likely to get translated into the containing host's IP address. However, it's about the closest you can get.
When using client IP addresses, bear in mind that the whole deal is far too touchy to be the primary security mechanism for any application. Knowing a source IP can be useful for auditing purposes, but not for actual protection. Then again, I've ranted repeatedly (and will again) on the unreliability of security systems designed by "clever people" when there are ready-made systems designed by full-time security professionals available, including one that's built right into Tomcat, whether you use it or not.
Joined: Oct 01, 2012
I have done by editing classes of StatusManager residing in catalina.jar file.