On Jul 7, 1:46 pm, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Christopher Weimann wrote:
> > REMOTE_ADDR is typically set by your webserver and can be trusted.
> > X_FORWARDED_FOR is an HTTP header typically set by proxy servers or even
> > the client and I would have to say it can NOT be trusted so should
> > certainly not replace the reliable data in REMOTE_ADDR.
> This is in part the reason why it is handled in middleware. If you *do*
> have a proxy in your installation then you can (and should) trust
> X-Forwarded-For, and moving it to REMOTE_ADDR signifies the
> trustworthiness of the value. If you are not behind a proxy you should
> ignore the value. (Arguably, maybe you should even remove the header or
> reject the request, but nothing currently does that.)
Correct.
The middleware I use under modperl works like this:
Port 80 proxy-
Sets X-Forwarded-For to REMOTE_ADDR
Sets X-Forwarded-For-Lan to LAN_SECRET
Sets REMOTE_ADDR to the lan id / 127.0.0.1
ModPerl 'middleware'
Requires X-Forwarded-For headers to have:
REMOTE_ADDR of specifc lan ips
X-Forwarded-For-Lan with correct lan secret
If those qualifications are met, then the X-Forwarded-For becomes
REMOTE_ADDR. If they do not, the request is rejected.
This approach ensures that data IS reliable, and GREATLY simplifies
development and clustering across load balancers.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
