Always supply a user.ip_address value

This is explicitly choosing to also parse the X-Forwarded-For header to
yank out this value. Otherwise, the Sentry server relies only on the
REMOTE_ADDR value which will always be wrong when when someone is behind
a reverse proxy.

This logic already exists in some other clients, and this has been
brought up a number of times with users via tickets and support.

Worth noting that it's potentially possible for this value to now be
forged from a user, but the ramification of doing so is so low, it's not
worth putting this behavior behind a feature flag IMO. The worst someone
could do is make some data inside Sentry inaccurate and possibly
confusing. No worse than the current state of the world where the data
is completely inaccurate.

1 files changed, 14 insertions, 0 deletions

diff --git a/raven/utils/wsgi.py b/raven/utils/wsgi.py
index f68bd5e..71f4679 100644
--- a/raven/utils/wsgi.py
+++ b/raven/utils/wsgi.py
@@ -92,3 +92,17 @@ def get_current_url(environ, root_only=False, strip_querystring=False,
             if qs:
                 cat('?' + qs)
     return ''.join(tmp)
+
+
+def get_client_ip(environ):
+    """
+    Naively yank the first IP address in an X-Forwarded-For header
+    and assume this is correct.
+
+    Note: Don't use this in security sensitive situations since this
+    value may be forged from a client.
+    """
+    try:
+        return environ['HTTP_X_FORWARDED_FOR'].split(',')[0].strip()
+    except (KeyError, IndexError):
+        return environ.get('REMOTE_ADDR')