-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Janko Hauser wrote: > > 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 >> 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?
The sequence which creates a user object is defined in the PAS.validate method: - Allow all registered "credentials extraction" plugins to do their thing, returning credentials objects (usually dicts) - Iterate over the credentials objects, allowing each authentication plugin to test them, and build up a list of candidate user IDs. - Iterate over the user IDs, allowing each "user factory" plugin to attempt create a user with that ID; default to a simple PropertiedUser. - If the user is not authorized to acess the published object, and we are the top-most user folder, then return an anonymous user. Note that the "decorating" plugins get a chance to scribble on the user *before* the access is checked, which makes it possible to add roles, groups, etc. via plugins. If the returned user cannot validate, or if the application raises Unauthorized, then the PAS challenge machinery kicks in, via the PAS '_unauthorized' method (which gets mangled onto the response): - Ask any plugins registered for "challenge protocols" to enumerate valid protocols for the request (so that we *don't* do a redirect to a login form for a WebDAV request, for instance). - Iterate over the challenge plugins which are valid for those protocols, allowing them to issue a challenge by modifying the response. The protocol of the first plugin to issue a challenge becomse the only protocol allowed for the remainder of processing. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v18.104.22.168 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEmp2A+gerLs4ltQ4RAvHaAKCTbYVAmxicAAHK1Zieb+R+whCXqACdG47Z AQONzpcvf8dBbZe/O9v4KxE= =GOMn -----END PGP SIGNATURE----- _______________________________________________ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas