Mailing List Archive

On Thu, 10 Feb 2000, Bill Anderson wrote:

> When trying to make an SQL Members based portal, it always fails on the
> last step, where it creates the initial adminstrator; apparently trying
> to acess things that don't exist I looked in the docs, but see nothing
> about whether I need to set up the table in the db myself, or if the
> wizard will set up the table for me? If the former, what is it looking
> for?

I'm not actually going to suppose this SQL implementation, since
Membership is going to be reworked (later today?) to use the LoginManager
product from Phillip Eby and Ty Sarna.

But, here's some hints. You need to set up two tabels, one called
'users' and one called 'propertysheets'. 'users' four columns,
'username', 'password', 'domains' and 'roles'. 'propertysheets' has four
columns, 'username', 'propertysheet', 'property' and 'value'. If
possible, 'user' should be indexed in the first, and everything but
'value' in the second.

I'm glad to hear you at least got as far as you did. I haven't
touched the SQL stuff in about a billion years!

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

> On Thu, 10 Feb 2000, Bill Anderson wrote:
>
> > When trying to make an SQL Members based portal, it always fails on the
> > last step, where it creates the initial adminstrator; apparently trying
> > to acess things that don't exist I looked in the docs, but see nothing
> > about whether I need to set up the table in the db myself, or if the
> > wizard will set up the table for me? If the former, what is it looking
> > for?
>
> I'm not actually going to suppose this SQL implementation, since
> Membership is going to be reworked (later today?) to use the LoginManager
> product from Phillip Eby and Ty Sarna.
>
I have been playing with SQLMembers as well and even after I
create the tables it still fails with various obscure errors. If it is going
to be reworked though I'll stop chasing this and do something else
for a few days.

--
Duncan Booth duncan@dales.rmplc.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
http://dales.rmplc.co.uk/Duncan

Mike Pelletier wrote:
>
> On Thu, 10 Feb 2000, Bill Anderson wrote:
>
> > When trying to make an SQL Members based portal, it always fails on the
> > last step, where it creates the initial adminstrator; apparently trying
> > to acess things that don't exist I looked in the docs, but see nothing
> > about whether I need to set up the table in the db myself, or if the
> > wizard will set up the table for me? If the former, what is it looking
> > for?
>
> I'm not actually going to suppose this SQL implementation, since
> Membership is going to be reworked (later today?) to use the LoginManager
> product from Phillip Eby and Ty Sarna.

Any updates on this yet?
I have yet to look into LoginManager much yet.

Were the changes made, if so what were they?

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

On Sat, 11 Mar 2000, Bill Anderson wrote:

> Any updates on this yet?
> I have yet to look into LoginManager much yet.

As you probably noticed, you can now set up a DemoPortal which uses
the LoginManager. The only useful reason to do so, IMO, are the
LoginMethods portion of LoginManager. The rest (UserSources, property
sheets) are not complete enough to replace the training-wheels
implementation that the PTK installs.

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

> Were the changes made, if so what were they?

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.

Mike.

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

Mike Pelletier wrote:
>
> On Sat, 11 Mar 2000, Bill Anderson wrote:
>
> > Any updates on this yet?
> > I have yet to look into LoginManager much yet.
>
> As you probably noticed, you can now set up a DemoPortal which uses
> the LoginManager. The only useful reason to do so, IMO, are the

Yes, I noticed (recently got a new cvs dump).

> LoginMethods portion of LoginManager. The rest (UserSources, property
> sheets) are not complete enough to replace the training-wheels
> implementation that the PTK installs.

I noticed ;)
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?

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

> > Were the changes made, if so what were they?
>
> 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.

So, addMember is now called y the Portal itsself, to be defined in
whatever form of authentication is chosen?

Cool.

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

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

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

On Wed, 15 Mar 2000, Bill Anderson wrote:

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

In your version, is there a PTKBase/register.py module? If not, there
will be a little work to get your objects working after you update. The
just-mentioned module now handles the registration of new PortalContent
thingums. It has a descriptive doc string, and additional documentation
in interfaces.

> 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)?

Python:


def memberLifeTime(self, member):
return DataTime() - \
member.getPropterySheet('MemberData').MemberSince


DTML:


<dtml-with "AUTHENTICATED_USER.getPropertySheet('MemberData')">
<p>You've been a member since &dtml-MemberSince;</p>
</dtml-with>


> 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 :(

Nope, these property sheets are a ZClass feature. It will eventually
be a feature of some component of LoginManager (I forget the name) but I'm
faking it with ZClasses for now. That is why you can't just go though
'self.propertysheets' as you normally would for a ZClass. (That would cut
LoginManager out of the loop for ZClass member objects, and simply not
work for other member objects.)

> OK, got it.
> SO LoginMehtods would be where I would implement say, an login via
> Cookie, BasicAuth, DigestAuth(when supported), etc., correct?

Bingo. That is so.

Mike.

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

Mike Pelletier wrote:
>
> On Wed, 15 Mar 2000, Bill Anderson wrote:
>
> > 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).
>
> In your version, is there a PTKBase/register.py module? If not, there
> will be a little work to get your objects working after you update. The
> just-mentioned module now handles the registration of new PortalContent
> thingums. It has a descriptive doc string, and additional documentation
> in interfaces.

Nope. It exists not.


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