Code for this is pretty simple:

modify 2 files, ZServer/medusa/ and 

1.  To put the proxy-passed ip address in the zserver log,

Around line 269 in ZServer/medusa/, add a method 

def client_ip(self):
        proxy_client = self.get_header('x-forwarded-for')
        if proxy_client:
            return proxy_client

Then around line  294, change the statement that does logging to use the 
            ' - %s [%s] "%s" %d %d "%s" "%s"\n' % (

2.  If we want to get fancy about allowing authentication using that ip 
address like naked ZServers can do,

In lib/python/AccessControl/, around line 1116,

    if request.has_key('REMOTE_ADDR'):


if request.has_key('HTTP_X_FORWARDED_FOR'):
    elif request.has_key('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:
>Once we get the commitments up to date, we can start wrangling 
>with the vetting...

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to