-----BEGIN PGP SIGNED MESSAGE-----
>> 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
> 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
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.
>>> 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
> 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 Seaver +1 540-429-0999 [EMAIL PROTECTED]
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
-----END PGP SIGNATURE-----
Zope-PAS mailing list