[Zope-PTK] SQLMembers Based Portal Q

[Mike Pelletier]

On Tue, 14 Mar 2000, Bill Anderson wrote:

> If I had more time available (got a lottery ticket! ;) ), I'd help more
> with it. As it is, I have enough on my plate. I am curious about
> upgrading cvs code (the main reason I haven;t yet). How much will it
> break things?

    Well, that depends.  When was the last time you did an update, and
what code of your own uses the PTK?  Chances are, nothing will
break.  Yet.  The place to exercise caution is when using the
propertysheets of a Member.  You have to pretend that it's not a ZClass
and that you can't simply assume the properties on the sheets are in your
scope.  One day, they won't be.  You must reference them explicitly via
member.PropertySheets() or member.PropertySheet('sheet').

> >     LoginMethods are very useful and cool.  If you haven't looked into
> > what they are yet, I can give you an overview.

> Please. Especially if you can give an overview to hooking one into a db
> (UserSource, IIUC). :)

    LoginMethods don't have anything to do with fetching users.  As you
noted, that's the domain of UserSources.  I think that any general
LoginMethod should be able to work with any general UserSource, although a
'general' UserSource seems as though it will be a bit of a rarity.

    LoginMethods are responsible for identificaiton and authorization of
users.  They have one manditory method, 'findLogin'.  This method examines
the request data for whatever sort of credentials it is interested in to
identify and authenticate a user.  It uses the extracted identity to fetch
a user from the LoginManager, and then asks that user object to
authenticate itself against the extracted credentials.

    A LoginManager may have any number of LoginMethods.  Each gets a crack
at it.  If a previous LoginMethod has OK'd a user, later ones may veto the
decision, or based on additional credentials that they know to look for
can grant additional roles to the user.  Actually, they can do anything
they like to the user, and don't have to base their actions on
authentication data.  You could use it to implement time-of-day
restrictions, usage quotas, etc.

    For more detailed information, I direct you to 
ZopePTK/LoginManager/README.txt.

    As for UserSources...  I wouldn't recommend implementing one (for the
PTK, otherwise, go ahead) yet.  You would have to implement a lot of
propertysheet stuff yourself, because the LoginManager doesn't yet handle
it.  Perhaps you can fake it for now by placing persistent propertysheets
somewhere in the ZODB as I've done.

> >     A couple changes were made to the PTK in preparation for LoginManager.
> > The 'addMember' function was moved off of acl_users and onto the portal
> > object, and the means of working a Member's propertysheets changed.

    'function' should be 'method', of course.

Mike.

-- 
Mike Pelletier                          email: mike@digicool.com
Mild mannered software developer          icq: 7127228
by day, super villain by night.         phone: 519-884-2434