[Zope-PAS] Re: Domainauth

[Tres Seaver]

-----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          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEmp2A+gerLs4ltQ4RAvHaAKCTbYVAmxicAAHK1Zieb+R+whCXqACdG47Z
AQONzpcvf8dBbZe/O9v4KxE=
=GOMn
-----END PGP SIGNATURE-----