I built a proxy for Sentry events in order to create Sentry projects on demand and route traffic into the appropriate project based on metadata in the payload. We have a number of web properties with raven-js integration, so managing from a single place is desirable. This is working great, however, I noticed that we lose the client IP tracking - all of the events appear to originate from two IPs, which correspond to the public IP addresses of our proxy cluster.
The proxy would need to conform to the standard specs, and Sentry would need to be configured to accept the appropriate headers. If you’re hosting it yourself, this is the same as the Nginx configuration. If this is sentry.io it’s currently not possible.
If so, I can probably do that with a custom http.Transport on the reverse proxy, but it certainly would be nice if Sentry supported the standard X-Forward-For header, especially considering how many users could be sitting behind proxies. Is that possible?
The reason we don’t support it on the upstream server is that it’s based on a trust system. If we just accepted it by default any user could override their IP by passing that header.
That said, we could possibly have a setting which accepts it.
Hmm, spoofing might be harder than I thought. Golang seems to try hard to prevent that.
Thinking on it some more though, I’m not sure I follow the trust thing. Couldn’t an end user do any number of modifications to the data that is sent? In fact, there is nothing prevent a malicious user from invoking Raven.captureException() in the browser or spamming the sentry.io endpoint with gibberish (the project id and client key are in plaintext, after all). And of course, a particularly determined user could spoof their IP anyway (or hide behind some services that will).
I’m still in favor of accepting X-Forwarded-For by default, though per your suggestion an opt-in setting could work too. However, if it is at the project-level it would be great to have it configurable at creation time via the API. We’re in the process of rolling Sentry out to 100+ properties, and part of that integration is to automate the creation of the Sentry projects per-property. Requiring manual intervention for each new project wouldn’t be ideal.
The big thing with IPs is they’re the only reliable way we can prevent abuse.
e.g. You send data from X IP, we block X IP.
Regarding the option, pretty much everything these days is configurable via APIs, so this would be no different. I don’t know if you’d be able to do it from creation, but there’s other endpoints that we expose for mutating settings.
With that said, no promises on when we’ll actually deliver this feature. I definitely get the usability of it, but in terms of priorities its not something thats come up often. Someone may decide to take a stab at it given their interest, or if you’d like to we can help on a pull request. Otherwise it likely won’t happen at the very least before sometime next year.