[Zope-PTK] SQLMembers Based Portal Q

[Bill Anderson]

Mike Pelletier wrote:
> 
> 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


Err ... it has been a while. I would say about 5-6 weeks. As far as code
use, well, in the case I would be concerned over, pretty much nothing
other than a few added  PTK Content thingums (Event Announcememnt,
Product Review, etc).

> 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').


I saw reference to this. Fortunately, I haven't yet done much with
members-specific stuff that is not handled by the portal. On that note,
I have had a question I have been digging into on that. Let us say a
member has a property 'MemberSince' on PropertySheet 'MemberData'.
What is the proper way of referencing that item (in python and dtml if
you can)?

Secondly, is this 'feature' a PTK thing? I ask this one because I am
looking for a way to better abstract property placement for my
Advertising ToolKit (for lack of a better name!). If so, where would I
find this code. I've kinda got lost in the maze of imports so far :(

> > >     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.

OK, got it.
SO LoginMehtods would be where I would implement say, an login via
Cookie, BasicAuth, DigestAuth(when supported), etc., correct?
 
>     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.

This gets interesting. Verry interesting.

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

I'm there.
 
>     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.


Yeah, liek I said, I am attempting to implement something like that
elsewhere, and it is not ... pleasant.

> > >     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.

Duly noted.



-- 
In flying I have learned that carelessness and overconfidence are 
usually far more dangerous than deliberately accepted risks. 
          -- Wilbur Wright in a letter to his father, September 1900