-----BEGIN PGP SIGNED MESSAGE-----
Mark Hammond wrote:
> Hi Jens,
>> On 4 Feb 2007, at 23:24, Mark Hammond wrote:
>>> So to slightly change the focus of Sidnei's question: should PAS
>>> loudly when after enumerating all property related plugins, PAS
>>> fails to
>>> find *any* properties for a specific user?
>> I think you're mixing up a couple things, you brought roles into the
>> game as well.
> IIUC, in an LDAP environment the roles are generally filled based on the
> groups the user belongs to. Without a list of groups, the roles are
> generally incorrect. Without user-properties for a user, there are no
> groups, and therefore no roles. I understand different interfaces provide
> these roles, but in this case they all ultimately are derived from the
> properties fetched (or in this case, *not* fetched).
> For my information, what things am I mixing up?
>> For pure properties PAS should *not* complain. The
>> basic user folder behavior doesn't even use and expect them, either.
>> Maybe if a user has no roles it may complain, but even then I'm not
>> This whole properties issue looks very much like a "site policy"
>> decision to me.
> We've been mixing up functionality and implementation. Let's look at this
> another way:
> If PAS fails to find the user that is being logged in, should it (a)
> complain or (b) allow the user to login, but with that user having *no*
> properties at all?
If it can validate credentials, however those credentials are extracted
and checked, then yes. There is *no* generic requirement that a user
have any properties.
If your site depends on externally-provided properties to generate stuff
which is"critical" of the application, then you might need to modify the
*plugin* which is supposed to fetch them (or perhaps, which depends on
them already being fetched), to log the problem. An alternative would
be to raise an exception from within the properties, roles, or groups
plugin: PAS doesn't swallow *any* exceptions from them.
Raising an exception seeme reasonable in this case, which is essentially
an *operational* problem (e.g., the LDAP server is down) or a
misconfiguration (a plugin is wired up to build the *wrong* properties),
not one which a "normal" production site would ever see.
> I believe that for the vast majority of sites, the correct answer should be
I don't think the "vast majority" of sites depend on *any* external
store for anything at all.
> Some sites may want a policy that allows (b), but I can't think of a
> reasonable use for that.
> If we can agree on the desired semantics, we can then look at
> implementation. Currently PAS only allows for (b) - do people believe the
> semantics of (b) are a better default than (a)?
At the PAS level, we could add a new plugin interface, something like
'IIsUserValid', which would be called just after the roles plugins, and
which would block returning any user at all if "required" properties for
the site were not present.
Tres Seaver +1 540-429-0999 [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
-----END PGP SIGNATURE-----
Zope-PAS mailing list