BACKWARDS-INCOMPATIBLE CHANGE: Removed SetRemoteAddrFromForwardedFor middleware.

In a nutshell, it's been demonstrated that this middleware can never be made reliable enough for general-purpose use, and that (despite documentation to the contrary) its inclusion in Django may lead application developers to assume that the value of ``REMOTE_ADDR`` is "safe" or in some way reliable as a source of authentication. So it's gone.

See the Django 1.1 release notes for full details, as well as upgrade instructions.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@11363 bcc190cf-cafb-0310-a4f2-bffc1f526a37

django/middleware/http.py

@@ -1,3 +1,4 @@
+from django.core.exceptions import MiddlewareNotUsed
 from django.utils.http import http_date
 
 class ConditionalGetMiddleware(object):
@@ -32,24 +33,19 @@ class ConditionalGetMiddleware(object):
 
 class SetRemoteAddrFromForwardedFor(object):
     """
-    Middleware that sets REMOTE_ADDR based on HTTP_X_FORWARDED_FOR, if the
+    This middleware has been removed; see the Django 1.1 release notes for
-    latter is set. This is useful if you're sitting behind a reverse proxy that
+    details.
-    causes each request's REMOTE_ADDR to be set to 127.0.0.1.
+    
-
+    It previously set REMOTE_ADDR based on HTTP_X_FORWARDED_FOR. However, after
-    Note that this does NOT validate HTTP_X_FORWARDED_FOR. If you're not behind
+    investiagtion, it turns out this is impossible to do in a general manner:
-    a reverse proxy that sets HTTP_X_FORWARDED_FOR automatically, do not use
+    different proxies treat the X-Forwarded-For header differently. Thus, a
-    this middleware. Anybody can spoof the value of HTTP_X_FORWARDED_FOR, and
+    built-in middleware can lead to application-level security problems, and so
-    because this sets REMOTE_ADDR based on HTTP_X_FORWARDED_FOR, that means
+    this was removed in Django 1.1
-    anybody can "fake" their IP address. Only use this when you can absolutely
+    
-    trust the value of HTTP_X_FORWARDED_FOR.
     """
-    def process_request(self, request):
+    def __init__(self):
-        try:
+        import warnings
-            real_ip = request.META['HTTP_X_FORWARDED_FOR']
+        warnings.warn("SetRemoteAddrFromForwardedFor has been removed. "
-        except KeyError:
+                      "See the Django 1.1 release notes for details.",
-            return None
+                      category=DeprecationWarning)
-        else:
+        raise MiddlewareNotUsed()
-            # HTTP_X_FORWARDED_FOR can be a comma-separated list of IPs. The
-            # client's IP will be the first one.
-            real_ip = real_ip.split(",")[0].strip()
-            request.META['REMOTE_ADDR'] = real_ip

docs/ref/middleware.txt

@@ -122,17 +122,10 @@ Reverse proxy middleware
 
 .. class:: django.middleware.http.SetRemoteAddrFromForwardedFor
 
-Sets ``request.META['REMOTE_ADDR']`` based on
+.. versionchanged: 1.1
-``request.META['HTTP_X_FORWARDED_FOR']``, if the latter is set. This is useful
-if you're sitting behind a reverse proxy that causes each request's
-``REMOTE_ADDR`` to be set to ``127.0.0.1``.
 
-**Important note:** This does NOT validate ``HTTP_X_FORWARDED_FOR``. If you're
+This middleware was removed in Django 1.1. See :ref:`the release notes
-not behind a reverse proxy that sets ``HTTP_X_FORWARDED_FOR`` automatically, do
+<removed-setremoteaddrfromforwardedfor-middleware>` for details.
-not use this middleware. Anybody can spoof the value of
-``HTTP_X_FORWARDED_FOR``, and because this sets ``REMOTE_ADDR`` based on
-``HTTP_X_FORWARDED_FOR``, that means anybody can "fake" their IP address. Only
-use this when you can absolutely trust the value of ``HTTP_X_FORWARDED_FOR``.
 
 Locale middleware
 -----------------