[Zope-PTK] Membership packaging
Phillip J. Eby
Sun, 04 Jun 2000 22:14:50 -0500
At 12:23 PM 6/5/00 +1000, Andrew Kenneth Milton wrote:
>I think we need a broader concept of what a User is, and we need a
>conceptual User Management Product.
Actually, that's what LoginManager is intended to be. In ZPattern
framework terms, it is intended to be a "Specialist" for participants in an
application/site. (A Specialist is a gathering point for placing
application-level methods which deal with objects that fill a specific role
in an application.)
>o Membership Manager
> which handles roles and stuff like mailing out passwords
> if you've stored them in plain text, or providing the 'hint' questions
> if you've stored them encrypted.
The idea here is that you add methods for this on LoginManager's "Methods"
tab. They can be DTML methods/documents representing pages that people go
to, or other kinds of methods that are called from elsewhere in the
application. And of course the portal manager/developer is free to define
and place additional methods here that are specific to their portal's needs.
>o Property Manager
> This obviously handles the attributes of a user in some way. It
> deals with the storage and retrieval of those properties. So the
> simplest case would be for it to create document in a folder with
> for each username and add properties to it. You could then add a
> ZCatalog solution, an SQL solution, an LDAP solution etc..
The ZPatterns framework from which LoginManager derives already has support
for "sheet providers" and "attribute providers" which can supply the data
for properties and propertysheets. You can create as many kinds of such
providers as you like, and add them to the appropriate tabs on LoginManager
or on any specific UserSource. This is done through the Zope management
interface. If one creates an LDAP attribute/sheet provider class or SQL
sheet provider class and registers it as a ZPatterns plugin, the class will
automatically appear on the "add list" of the appropriate tabs of all
LoginManagers and UserSources.
>I haven't really given much though about how to plug it all together, but,
>I don't think we want some MegaLogin Product that does all of this stuff
>as it will get too complicated. If stuff is broken down into smaller plug
>ins we get the benefits of 3rd party mix 'n' match stuff. Using LDAP for
I agree, which is why ZPatterns and LoginManager were built to allow such