[Zope-PTK] PTK, LoginManager and user maintenance

[Dan L. Pierson]

Phillip J. Eby writes:
 > At 11:44 AM 5/24/00 -0400, Dan L. Pierson wrote:
 > >
 > >Ah so, PTK should do something like the following?
 > >
 > >            manage_addLoginManager(self,
 > >                                   'Persistent User Source',
 > >                                   ['Basic Cookie Login', 'Basic Auth
 > Login'],
 > >                                   0, 0, 0)
 > >            # self.acl_users was magically created by the above call
 > >            self._getPUS().manage_setStorage('DemoPortal/LoginMember')
 > >            self.acl_users.manage_addDocument('addUser', '',
 > 'dtml/addUser.dtml)
 > 
 > Yes.  That's what Ty and I proposed to Mike; I think he just never got
 > around to implementing it.
 > 
 > The whole _getPUS thing probably doesn't belong there, though, unless
 > there's some other reason the Portal object needs to know about the
 > specific UserSource.  And even if it does, the portal should just add
 > methods to the LoginManager to do whatever it needs involving members.
 > Then the portal developer can edit those methods without subclassing the
 > portal!
 
Yeah, _getPUS is an ugly hack that wraps the even uglier couple of
lines of code that searches for the first 'Persistent User Source' in
the UserSources.  All of this needs to be replaced by a cleaner
interface to user folders in general.  The outer part of the code
above looks like:

        # Determine membership storage and create acl_users
        #  Because SQLMemberFolder requires nonstandard arguments, I cannot
        #  use PTKBase.PortalBase.addMemberFolder
        db = REQUEST['database']
        if db == 'ZODB':
            ...
        elif db == 'LoginManager':
            ...
        else:
            ...SQLMemberFolder...

        # I'm not sure why this is done via this() but this is what
        # addMemberFolder does, so I do as well.
        self.this().__allow_groups__=self.acl_users

There are one or two other places in Portal.py where this sort of
thing happens.

Clearly one of two things needs to be done:

1. PTK is changed to always use LoginManager and all the other options 
are wrapped as UserSources.

2. PTK grows a user folder abstraction that hides user folder
differences from the main portal code.  The PTK creation wizard then
calls the user folder abstraction with appropriate arguments.  This
sounds like replicating a bunch of stuff that LoginManager already
does, but I don't know if others would find it acceptable to make PTK
require LoginManager quite yet.

I hope to have time to do something about this after I get back from
vacation.