Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of 2.6...
Jim Washington
jwashin@vt.edu
Wed, 10 Apr 2002 12:16:35 -0400
Support for X-HTTPD-FORWARDED-FOR
Code for this is pretty simple:
modify 2 files, ZServer/medusa/http_server.py and
lib/python/AccessControl/User.py
1. To put the proxy-passed ip address in the zserver log,
Around line 269 in ZServer/medusa/http_server.py, add a method
http_request::client_ip
def client_ip(self):
proxy_client = self.get_header('x-forwarded-for')
if proxy_client:
return proxy_client
else:
return self.channel.addr[0]
Then around line 294, change the statement that does logging to use the
method.
self.channel.server.logger.log (
self.client_ip(),
' - %s [%s] "%s" %d %d "%s" "%s"\n' % (
name,
...
2. If we want to get fancy about allowing authentication using that ip
address like naked ZServers can do,
In lib/python/AccessControl/User.py, around line 1116,
change
if request.has_key('REMOTE_ADDR'):
addr=request['REMOTE_ADDR']
to
if request.has_key('HTTP_X_FORWARDED_FOR'):
addr=request['HTTP_X_FORWARDED_FOR']
elif request.has_key('REMOTE_ADDR'):
addr=request['REMOTE_ADDR']
I do not believe this does anything to authentication that is not
possible now regarding spoofed ip addresses, so probably not a major
security headache.
Major possible problem I can think of: I do not use ZEO, and have no
idea what these changes might do there. I do not have check-in
privileges, and probably should not until I get a better clue of how cvs
works :).
Anyway, here is the code FWIW. Apologies that it is not a patch per se.
Now looking for a more clueful sponsor to take it from here to check-in
(after vetting?)
-- Jim Washington
Brian Lloyd wrote:
>...I sent out a note a while ago now trying to scare up
>some ideas on how to vet the current list of 2.6 proposals
>and get to a final "plan". I didn't get much (any?) response :(
>
>For a couple of things that were ready to go and fairly non
>controversial (like Toby's unicode work), I put on the BDFL
>hat and said "merge it!".
>
>But there are still a lot of things on the proposed features
>that are undone, and some that are controversial enough that
>we need to get to closure on them.
>
>I'll volunteer to convert the current proposed feature list
>into a draft "plan", where the conversion boils down to
>adding some columns to the table:
>
>Proposal - name and link to the proposal
>
>Resources - who is working on it
>
>Committed - Y/N whether the volunteers have committed to have
> the implementation and docs done by the first week
> in June. I'll fill in what I know has been committed
> to, people can update this (or let me know and I'll
> do it), and anything that doesn't get a 'Y' in a
> reasonably short time will be put in the cooler.
>
>Vetted - Y / N whether the community and / or the relevant BDFLs
> have come to some agreement on whether it *should* be
> done. The list of items without a 'Y' will be our next
> order of business. Getting to closure on those either
> via the list, IRC, or whatever is the main block on the
> critical path.
>
>Status - Complete or incomplete
>
>
>I've taken a first stab at this. I've set the "committed" to 'Y'
>for those things that I know I've gotten commitments for. For
>those set to 'N', please let me know if you can commit to the
>date (or change it yourself in the wiki).
>
>The updated plan is at:
>
>http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures
>
>
>Once we get the commitments up to date, we can start wrangling
>with the vetting...
>