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... > _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )