[Zope-PAS] Re: PluggableAuthService and PrincipalDeleted

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Miles wrote:

>> I've never been happy with the idea of PAS "supporting" any changes to
>> the plugins:  even the IUserAdderPlugin and IUpdatePlugin are out of
>> place, in my opinion, because they try to generalize without knowing
>> enough:  they exist to support a not-really-a-contract of the "stock"
>> Zope user folder ('_doAddUser').
>>
>> CRUD on the user objects is really a separate application (*not* a
>> framework), which is not even possible in many applications where PAS is
>> appropriate.
> 
> I always thought that was the *point* of declaring plugins with specific 
> interfaces: in those applications where it's not possible, you can just 
> turn them off and they then have no effect.  I'm not sure it's sensible 
> to ask people to develop a completely separate application to do it just 
> because a subset of use-cases don't need it.

The point is that PAS is about authenticating and authorizing users:
the abstractions for those use cases are pretty solid, with *lots* of
real-world validation.

I don't think we know enough yet to do a good job of writing a similar
framework for *managing* users atop a n arbitrary set of user / group /
role / property stores.  Lots of "partial solutions" (i.e., applications
which work fine against a given set of plugins) exist, certainly, but
the APIs used by those applications don't show a lot of commonality.

Originally, PAS was intended to have *no* generic support for adding /
updating / removing users and their associated metadata:  we included
the IUserAdder bit only as a hack to allow a PAS to support some of the
"legacy" APIs form AccessContrul.User.BaseUserFolder.

> <snip>
>>> IIRC, I got a bit confused when it came to password resets, as to 
>>> whether a password was considered a user property or as something else - 
>>> passwords are passed to the UserManager at creation so should they go to 
>>> the PropertyUpdater too?
>> Passwords are *not* properties:  plugis implementing IUpdatePlugin
>> should not know about them, unless they are also actively registered for
>> ICredentialsUpdatePlugin.
> 
> Yes, though the interface documentation makes it sound as if it should 
> only be used for a user changing their own password (rather than a 
> manager changing a user's password).  If that's not the case, I'll 
> happily submit a "documentation patch" to clarify.

You are correct that ICredentialsUpdatePlugin is intended to allow
plugins which have 'cached" the current user's credentials (cookie /
session auth, mostly) to update those caches.  Again, the fromawork is
*not* well-defined for arbitray CRUD operations, which are out of scope
for PAS *by design.*  Essentially, this is a layering problem:  the
"core" PAS stuff should be in a layer *below* any CRUD application or
framework, in order to avoid coupling / dependencies induced by the
"higher" layers on systems which don't need or want them.

I would like to see somebody ship a separate package which supplied the
UI for configuring the "stock" PAS components from somewhere besides the
ZMI view.  Such an application could work by defining marker interfaces
for the "CRUD"-able plugins, and supplying adapters for the "stock"
plugins, or it could just register views directly for those plugins.

PlonePAS does some of theneeded UI work in a Plone context. I find
PlonePAS a bit frustrating to work with, however:  some of its own
plugins have incomplete or missing GenericSetup support, and I strongly
question the fact that setup code replaces the parent user folder
(breaking the DelegatingMultiPlugin, amongh other things).


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIIz3f+gerLs4ltQ4RAvBaAKCstkNmrLxsOh0l9+g59F3yUs40wACghHzM
RF41vOCA3dyYGbyq8aW1UyI=
=HyRE
-----END PGP SIGNATURE-----