Since there seems to be two use cases, might I suggest forking the secondary use case into a separate middleware class?
Whether or not the trusted reverse proxy scenario is more common (though I believe it is), it's best to avoid breaking existing functionality, especially when the SetRemoteAddrFromForwardedFor docstring already stated not to use it with untrusted sources. Perhaps SetRemoteAddrFromUntrustedForwardedFor middleware, with the secondary implementation? Chris On Sep 20, 8:58 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > Howdy folks -- > > So I need a bit of help figuring out how to handle X-Forwarded-For, > and specifically what to do in the presance of multiple IPs. > > Django's SetRemoteAddrFromForwardedFor middleware used to take the > *first* item in the X-F-F header, but > afterhttp://code.djangoproject.com/ticket/3872was filed we changed it to > take the *last* IP. > > Now we're getting reports that the IP we want is, in fact, the first > IP after all (a fact confirmed > byhttp://en.wikipedia.org/wiki/X-Forwarded-For-- if Wikipedia is > capable of actually confirming anything :) > > Is there anyone on this group who's got a pretty good knowledge of all > the various HTTP proxies and can provide some advice? Obviously we've > got to pick one IP; which should it be? > > Jacob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
