On 9/20/07, Deryck Hodge <[EMAIL PROTECTED]> wrote: > I guess I would challenge the notion, too, that you can't trust the > client IP when you trust the proxy or proxies, at least in the sense > of knowing trusted proxies versus untrusted. For example, if my setup > has proxies p1 and p2: > > client (untrusted) --> p1 --> p2 --> django > > Can't I trust p1 and p2 to setup client IP appropriately in XFF > between the two of them? It's not like p1 or p2 are going to read the > XXF header from the untrusted client.
Yes, of course they *are* going to read it. Otherwise, how would they assemble the XFF header? (Yeah, proxys could have a option to white-list known proxys downstream, but they do?). > If they do, the problem is in > proxy trust, and I don't think Django can be asked to account for > this. Note that at least mod_proxy trust the client: http://bob.pythonmac.org/archives/2005/09/23/apache-x-forwarded-for-caveat/ And as I already said, I think that most of proxies out there just trust what the client sends, because otherwise you'd never end with more than one IP on the XFF header. To give a bit of perspective: IMHO, the problem is that we are giving users the illusion that this middleware will always setup the right remote IP when they trust their proxy server. It won't. And now, as it seems that the case I was advocating for isn't the common case, I think you were right: documentation can fix it, saying loudly that, *when using this middleware, you can't trust the remote IP, even if you trust the proxy server*. That's all. -- Leo Soto M. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
