Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

requestLogger setting localhost as clientIp #18

Closed
pbrisbin opened this issue Jul 20, 2022 · 0 comments · Fixed by #19
Closed

requestLogger setting localhost as clientIp #18

pbrisbin opened this issue Jul 20, 2022 · 0 comments · Fixed by #19

Comments

@pbrisbin
Copy link
Member

We're seeing clientIp as a 127.0.0.1 address in request logs.

It looks like bugsnag-wai has an approach that looks at the first value of X-Forwarded-For, then X-Real-Ip, then Wai.remoteHost. I think we should copy that.

We currently just use Wai.remoteHost, which is apparently wrong in an AWS/ALB context.

pbrisbin added a commit that referenced this issue Jul 20, 2022
`Wai.remoteHost` is often localhost in proxied contexts. It's fine as a
final fallback, but we should be checking `X-Forwarded-For` or
`X-Real-IP` first. Adding another configuration point and improving the
default addresses this.

Fixes #18.

There aren't actual specifications for these headers, but they're
present in our AWS deployments and seem to behave as described here:

https://distinctplace.com/2014/04/23/story-behind-x-forwarded-for-and-x-real-ip-headers/

The client's IP address is appended to `X-Forwarded-For` each time a
proxy handles the request. Therefore, the very first value should be the
actual originating client's IP. `X-Real-Ip` _seems_ to be a late
addition to just provide the _final_ value from the forwarded-for again.

Trying these in turn should behave correctly in contexts that have these
headers.
pbrisbin added a commit that referenced this issue Jul 20, 2022
`Wai.remoteHost` is often localhost in proxied contexts. It's fine as a
final fallback, but we should be checking `X-Forwarded-For` or
`X-Real-IP` first. Adding another configuration point and improving the
default addresses this.

Fixes #18.

There aren't actual specifications for these headers, but they're
present in our AWS deployments and seem to behave as described here:

https://distinctplace.com/2014/04/23/story-behind-x-forwarded-for-and-x-real-ip-headers/

The client's IP address is appended to `X-Forwarded-For` each time a
proxy handles the request. Therefore, the very first value should be the
actual originating client's IP. `X-Real-Ip` _seems_ to be a late
addition to just provide the _final_ value from the forwarded-for again.

Trying these in turn should behave correctly in contexts that have these
headers.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant