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/ (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 this list # and it has set an X_FORWARDED_FOR header, ZPublisher copies REMOTE_ADDR # into X_FORWARDED_BY, and the last element of the X_FORWARDED_FOR list
  # 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 VirtualHostMonster)

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

Attachment: PGP.sig
Description: Signierter Teil der Nachricht

Zope-PAS mailing list

Reply via email to