Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of 2.6...

[Jim Washington]

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...
>