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