You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, we attach an IP address to the event if users opt-in to this via requestDataIntegration({ include: { ip: true } }). If this is enabled, we extract the IP address and add it to the event.
However, in scenarios where apps receive requests from a proxy, the IP address is often not the original IP address, but something like ffff:127.0.0.1. In this scenario, the "real" IP address can be found in a header.
We have code in relay that extracts these headers, if they are set, and sets the IP address based on this. Today, because of this we have two problems in the SDK:
If ip: true is configured in the SDK, we always set an IP address. Relay then never infers the IP from the headers, so we get the "wrong" IP address (e.g. the 127.0.0.1 one).
If ip: false, no IP will be set by the SDK, but if it is a proxy scenario the headers are today not filtered out, so relay will still infer this.
To fix this, we want to make two changes:
[ ] Look at headers in the SDK if ip: true is configured
[ ] Do not send these headers if ip: true is not configured
This way, we should have a more consistent outcome - either correct IP addresses is ip: true is opted-into, or else no IP addresses, no matter if it is a proxy/tunnel or not.
We can use these headers, which we currently look at in Remix:
X-Client-IP
X-Forwarded-For
Fly-Client-IP
CF-Connecting-IP
Fastly-Client-Ip
True-Client-Ip
X-Real-IP
X-Cluster-Client-IP
X-Forwarded
Forwarded-For
Forwarded
The text was updated successfully, but these errors were encountered:
This PR does three things:
1. It ensures we infer the IP (in RequestData integration) from
IP-related headers, if available.
2. It ensures we do not send these headers if IP capturing is not
enabled (which is the default)
3. It removes the custom handling we had for this in remix, as this
should now just be handled generally
Closes#13260
Description
Today, we attach an IP address to the event if users opt-in to this via
requestDataIntegration({ include: { ip: true } })
. If this is enabled, we extract the IP address and add it to the event.However, in scenarios where apps receive requests from a proxy, the IP address is often not the original IP address, but something like
ffff:127.0.0.1
. In this scenario, the "real" IP address can be found in a header.We have code in relay that extracts these headers, if they are set, and sets the IP address based on this. Today, because of this we have two problems in the SDK:
ip: true
is configured in the SDK, we always set an IP address. Relay then never infers the IP from the headers, so we get the "wrong" IP address (e.g. the 127.0.0.1 one).ip: false
, no IP will be set by the SDK, but if it is a proxy scenario the headers are today not filtered out, so relay will still infer this.To fix this, we want to make two changes:
[ ] Look at headers in the SDK if
ip: true
is configured[ ] Do not send these headers if
ip: true
is not configuredThis way, we should have a more consistent outcome - either correct IP addresses is
ip: true
is opted-into, or else no IP addresses, no matter if it is a proxy/tunnel or not.We can use these headers, which we currently look at in Remix:
The text was updated successfully, but these errors were encountered: