What's the difference between request.remote_ip and request.ip in Rails?

Question

As the title goes, you can get the client's ip with both methods. I wonder if there is any differences. Thank you.

in the source code there goes

"/usr/local/rvm/gems/ruby-1.9.3-p194/gems/actionpack-3.2.3/lib/action _dispatch/http/request.rb" 257L, 8741C

def ip   @ip ||= super end  # Originating IP address, usually set by the RemoteIp middleware. def remote_ip   @remote_ip ||= (@env["action_dispatch.remote_ip"] || ip).to_s end 

but I really don't know the implications.

Answer 1

request.ip returns the client ip even if that client is a proxy.

request.remote_ip is smarter and gets the actual client ip. This can only be done if the all the proxies along the way set the X-Forwarded-For header.

Answer 2

request.ip

request.ip is the basic ip detection provided by Rack::Request out of the box. Its current definition can be found at https://github.com/rack/rack/blob/master/lib/rack/request.rb.

The algorithm it follows is to first check the REMOTE_ADDR header for any untrusted IP addresses, and if it finds any, it chooses the first one listed. "Trusted" IP addresses in this case are IP addresses from the reserved private subnet ranges, but note that it matches by regex which is probably not the best way to do it. If there is no untrusted REMOTE_ADDR then it looks at the HTTP_X_FORWARDED_FOR header, and picks the last untrusted one listed. If neither of those reveals anyone it falls back to the raw REMOTE_ADDR which is probably 127.0.0.1.

request.remote_ip

request.remote_ip is enhanced IP detection provided by ActionDispatch::Request (which inherits from Rack::Request). This is the code shown in the question. As you can see, it falls back to request.ip unless action_dispatch.remote_ip is set on the @env. That is done by the RemoteIp middleware, which is included in the default Rails stack. You can see its source at https://github.com/rails/rails/blob/4-2-stable/actionpack/lib/action_dispatch/middleware/remote_ip.rb.

The RemoteIp middleware if enabled provides these additional features:

• Provides optional but default IP spoofing detection.
• Allows configuration proxy addresses to be filtered instead of relying only on defaults.
• Uses the IPAddr class to actually test IP ranges properly instead of relying on a brittle regex.
• Uses HTTP_CLIENT_IP as a source of potential IPs.

The algorithm is similar to request.ip but slightly different. It uses HTTP_X_FORWARDED_FOR from last to first, then HTTP_CLIENT_IP from last to first, then finally the last entry of REMOTE_ADDR. It puts those all in a list and filters proxies, picking the first remaining one.

IP Spoofing Detection

The IP spoofing detection provided by RemoteIp is not particularly powerful, all it does is raise an exception if the last HTTP_CLIENT_IP is not in HTTP_X_FORWARDED_FOR. This isn't necessarily a symptom of an attack, but it is probably a symptom of a misconfiguration or a mix of proxies using different conventions which are not producing a coherent result.

Which to Use

In a simple setup where your proxies are all local or on private subnets, you can probably get away with request.ip, but request.remote_ip should be considered the superior choice in general. If you are using proxies with public internet routing (such as many CDNs) then RemoteIp can be configured to give you correct client IPs out of the box, whereas request.ip will only be correct if you can get your upstream proxy to set REMOTE_ADDR correctly.

Secure Configuration

Now to address Tim Coulter's comment about spoofing. He's definitely right you should be concerned, but he's wrong that you can be spoofed if you're behind nginx or haproxy by default. RemoteIp is designed to prevent spoofing by choosing the last IP in the chain. The X-Forwarded-For spec specifies that each proxy append the requester's IP to the end of the chain. By filtering out whitelisted proxies, the last entry is guaranteed to be the client IP written by your first whitelisted proxy. There is one caveat of course, which is that you must actually be running a proxy that always sets/appends X-Forwarded-For, so Tim's advice should actually be opposite: only use request.remote_ip when you are running a proxy.

How To Configure for Public IP Proxies

That's all fine and good, but ActionDispatch::RemoteIp is already in the default middleware stack. How do reconfigure it to add my proxy CIDRs?!

Add this to your application.rb:

check_spoofing = true proxies = ["23.235.32.0/20", "203.57.145.0/24"] proxies += ActionDispatch::RemoteIp::TRUSTED_PROXIES config.middleware.swap ActionDispatch::RemoteIp,                        ActionDispatch::RemoteIp,                        true,                        proxies