[Zope-PTK] Membership packaging

[Phillip J. Eby]

At 09:51 PM 6/4/00 -0400, Kevin Dangoor wrote:
>
>Add "Membership" Things to LoginManager?
>
>Currently, on its own, LoginManager doesn't handle the signing up of users,
>mailing of forgotten passwords, etc. It doesn't even have methods for adding
>users, etc. I get the impression from the TODO file that Ty would like to
>beef up the UI so that it is more readily usable out of the box. It seems to
>me that the easiest way to make Membership a separate component is to take
>the Membership stuff from the PTK, and massage it into an optional component
>for LoginManager.
>
>The "Portal" object is then simplified to just add a LoginManager with all
>of the Membership bits.

If I may suggest, one very straightforward way of doing this is simply to
create a "Factory"/constructor in a Zope product that asks for the
necessary settings, then creates a LoginManager and throws default methods
in it.  Even with the current version of LoginManager, I believe that it
should not be necessary to go to Python code to make such a constructor;
everything should be callable from DTML.

At that point, the "membership" system is basically a more user-friendly
wrapper around LoginManager, similar to the way you can create an
SQLMethod/DTMLMethod combo using a "wizard" of sorts.  (Whether this would
actually use a PTK-style wizard is beside the point.)

Ty has actually proposed that we add a wizard registration mechanism to
ZPatterns, so that one could easily install this kind of wizard into a Zope
site, and then have it show up on a "wizard menu" for each object whose
meta_class has wizards registered.  So if someone created a "Membership"
wizard that was registered under LoginManager's meta_type, then it would
show up on a menu which would appear immediately after you added a
LoginManager.  You could then pick any of the LoginManager-related setup
wizards and customize your LoginManager.  Similar wizards would be handy
for various other ZPatterns systems.


>It seems to me that there should also be a setting for whether the cookie
>given to the user for cookie authentication is permanent or just for that
>browser session. I could see people wanting it either way. (Or maybe the
>setting should be number of minutes that the cookie should last, with "0"
>meaning permanent?)

This could be done using a LoginMethod subclassed from
BasicCookieLoginMethod, or by submitting a patch (hint, hint).  A
TokenCookieLoginMethod, to support GUF-style token cookies, might be good too.



>How should the portal manager add properties to the user? Should they
>replace the class or extend it through some mechanism (sheet/attribute
>providers?)? If the manager changes the class used for the users, what
>happens to the previously defined users?

In a PersistentUserSource/PersistentRack, nothing happens to the previous
users if you change the class.  If your users are stored external to ZODB,
they all effectively change to the new class as of the next transaction.
There's a note in the Rack code (the base for UserSource) that says where
dynamic class migration could be done, but I haven't put the code in
because I don't like "side-effect transactions", and dynamically migrating
would cause a write to the ZODB just for reading the object.  On the other
hand, I don't like making manage_setStorage go into every record and
rewrite it, either...