[Zope-PAS] Re: Failing to fill users properties, should it cause an error?

[Mark Hammond]

Hi Tres,

> 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

I fully understand the point you are making.  However, our app doesn't
depend on any critical properties as such.  It is really just a support
issue - a client complains that certain things are not working as expected
(eg, their roles are not as they expect, "member" properties not what they
expect, etc).  It is not clear to the admin that the problem is simply that
their user store is incorrectly configured and/or down.  If PAS complained a
little louder, that admin and his user would be saved alot of time and
grief.

> I don't think the "vast majority" of sites depend on *any* external
> store for anything at all.

I understand that is strictly true.  However, I was also under the
impression that a Plone site dealing with authenticated users will almost
always be configured such that user properties come from *somewhere* - and
that by implication, failure to get said properties is significant enough to
generate noise, even if not an explicit error.

> 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.

Sure - that would work fine, and would make alot of sense if we did have a
specific application with specific property requirements - but from the POV
of this discussion, we would consider a user valid if *any* of the installed
property plugins returned *any* properties for the user.  I assumed that
this would be a common requirement, but I'm happy to accept that this is not
the case.

Cheers,

Mark