BACKWARDS-INCOMPATIBLE CHANGE: Removed SetRemoteAddrFromForwardedFor middleware.

jacobian · jacobian · commit d78cf61c9920 · 2009-07-29T05:35:51.000Z
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
diff --git a/django/middleware/http.py b/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 @@ def process_response(self, request, response):
 
 class SetRemoteAddrFromForwardedFor(object):
     """
-    Middleware that sets REMOTE_ADDR based on 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.
-
-    Note that this does NOT validate HTTP_X_FORWARDED_FOR. If you're not behind
-    a reverse proxy that sets HTTP_X_FORWARDED_FOR automatically, do 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.
+    This middleware has been removed; see the Django 1.1 release notes for
+    details.
+    
+    It previously set REMOTE_ADDR based on HTTP_X_FORWARDED_FOR. However, after
+    investiagtion, it turns out this is impossible to do in a general manner:
+    different proxies treat the X-Forwarded-For header differently. Thus, a
+    built-in middleware can lead to application-level security problems, and so
+    this was removed in Django 1.1
+    
     """
-    def process_request(self, request):
-        try:
-            real_ip = request.META['HTTP_X_FORWARDED_FOR']
-        except KeyError:
-            return None
-        else:
-            # 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
+    def __init__(self):
+        import warnings
+        warnings.warn("SetRemoteAddrFromForwardedFor has been removed. "
+                      "See the Django 1.1 release notes for details.",
+                      category=DeprecationWarning)
+        raise MiddlewareNotUsed()
diff --git a/docs/ref/middleware.txt b/docs/ref/middleware.txt
@@ -122,17 +122,10 @@ Reverse proxy middleware
 
 .. class:: django.middleware.http.SetRemoteAddrFromForwardedFor
 
-Sets ``request.META['REMOTE_ADDR']`` based on
-``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
-not behind a reverse proxy that sets ``HTTP_X_FORWARDED_FOR`` automatically, do
-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``.
+.. versionchanged: 1.1
+
+This middleware was removed in Django 1.1. See :ref:`the release notes
+<removed-setremoteaddrfromforwardedfor-middleware>` for details.
 
 Locale middleware
 -----------------
