Am 22.06.2006 um 13:48 schrieb Zachery Bir:
Woops. Like I said, too long since I played in it. It runs
request.getClientAddr(), which does take HTTP_X_FORWARDED_FOR, but
only if the default REMOTE_ADDR is in an attribute called
`trusted_proxies`. From lib/python/ZPublisher/HTTPRequest.py (in
some 2.7 branch):
# The trusted_proxies configuration setting contains a sequence
# of front-end proxies that are trusted to supply an accurate
# X_FORWARDED_FOR header. If REMOTE_ADDR is one of the values in
# and it has set an X_FORWARDED_FOR header, ZPublisher copies
# into X_FORWARDED_BY, and the last element of the
# into REMOTE_ADDR. X_FORWARDED_FOR is left unchanged.
# The ZConfig machinery may sets this attribute on initialization
# if any trusted-proxies are defined in the configuration file.
trusted_proxies = 
(again, this is all if you're using mod_rewrite and
Thank you Zac, yes I'm using mod_rewrite and VHM. I added the trusty-
proxy directive into etc/zope.conf, but this seems to not work. But
on further on this route I added a patch from Dieter Maurer to
SiteAccess/VHM and I have now the right REMOTE_ADDR in the request.
But no access to secured pages :-)
Another thing I noticed it, that I see that a user authenticated by
the cookie-login runs through the code of domain_auth. And the cookie-
plugin is used for credential extraction. As far as I understand, the
actual authentication is done later. So if the cookie-plugin does not
found an appropriate cookie it redirects to the login-page and the
domain_auth plugin is never used?
With regards and thanks for the help,
Janko Hauser email: [EMAIL PROTECTED]
mobile: +49 1721 641552
Description: Signierter Teil der Nachricht
Zope-PAS mailing list