Hello,
PR #1224 has been merged to master last April but is not included in the latest release (2.0.6 as of December 2018). Is there a reason why this fix is not included?
My problem
We have a Rails-based Rack application deployed at a customer site.
The application can only be accessed through a VPN, which assigns client addresses in the 172.17.0.0/24 range, which is considered "trusted" by this code https://github.com/rack/rack/blob/2.0.6/lib/rack/request.rb#L419-L421 .
As a consequence, the X_FORWARDED_FOR list is filtered to an empty list and Rack fallbacks to REMOTE_ADDR, which looks like 10.128.0.1
On this environment, it is impossible to read the client IP address in the applications logs since all clients requests are logged as coming from IP 10.128.0.1 when it is actually 172.17.0.7 or 123.
Having #1224 included in a new release of this gem would allow us to have the first IP in X_FORWARDED_FOR as the client ip instead of the REMOTE_ADDR , which would be correct in most cases.
Hello,
PR #1224 has been merged to master last April but is not included in the latest release (2.0.6 as of December 2018). Is there a reason why this fix is not included?
My problem
We have a Rails-based Rack application deployed at a customer site.
The application can only be accessed through a VPN, which assigns client addresses in the 172.17.0.0/24 range, which is considered "trusted" by this code https://github.com/rack/rack/blob/2.0.6/lib/rack/request.rb#L419-L421 .
As a consequence, the X_FORWARDED_FOR list is filtered to an empty list and Rack fallbacks to REMOTE_ADDR, which looks like 10.128.0.1
On this environment, it is impossible to read the client IP address in the applications logs since all clients requests are logged as coming from IP 10.128.0.1 when it is actually 172.17.0.7 or 123.
Having #1224 included in a new release of this gem would allow us to have the first IP in X_FORWARDED_FOR as the client ip instead of the REMOTE_ADDR , which would be correct in most cases.