At 02:06 PM 2/6/00 +1100, Stuart 'Zen' Bishop wrote:
>
>getUserNames has to be there to support the Zope management interface
>(eg. assigning a local role). Although this interface still works for
>3000 users, I'm fairly certain I'm going to have to start patching it
>to work with 40000...
Mike has offered to "sneak in" a patch to the DTML for the local roles
assignment screen that simply uses a text field for the user name instead
of a select list, being as the current interface sucks to use even for much
smaller lists than 3000 users.
>It seems that way. Some problems GUF tried to solve (being able to
>seperate the role membership, authentication, valid domains and
>now user properties) have now been pushed down to the user object.
>The valid user list has been factored out into the UserSource.
>
>There exists a need for all of these functions to be pluggable.
In the latest version of the LoginManager (formerly UUF) code, the base
class for User objects delegates the getRoles, getDomains, and authenticate
methods back to its UserSource, allowing a GUF-like UserSource to work. I
haven't finished the GUS (Generic User Source) yet, but about all it lacks
right now is a little transformation code (that could be lifted from GUF)
and a proper Zope management interface.
>It would be nifty (but probably outside the scope of an initial release)
>if multiple components could be selected as sources for the userproperties.
>In this way I could have multiple property sheets from different sources
>(possibly readonly). There would have to be a property sheet called
'default'
>which is read/write for applications such as PTK which need a
>backend-independant method of storing properties.
I expect we'll make an initial release this week. I've already written
three LoginMethod classes (Basic Auth, REMOTE_USER, and Basic Cookie), and
if you like the LoginManager system overall, I imagine you might want to
create a TokenCookie LoginMethod class using code from GUF. :)
I still need to bone up on the propertysheets protocol in order to add it
in to the base User and UserSource classes, but I don't think it'll be too
difficult to define a delegation protocol for it. Creating a good way of
plugging propertysheet implementations into a UserSource, however, is going
to be a bit trickier, I think.
Ty and I are pretty excited about the project. I can't wait to transform
our custom user folders into UserSources and drop all the duplicated
validation code. Plus the idea of being able to later add a LoginMethod
for say, SSL client certificates, without having to change any UserSource
code, is just phenomenal. And getting property sheets to be available is
cool too. One of our folders is LDAP based and it would be just great to
put all the LDAP attributes on a property sheet, and provide editing, too.
>
>getUserNames has to be there to support the Zope management interface
>(eg. assigning a local role). Although this interface still works for
>3000 users, I'm fairly certain I'm going to have to start patching it
>to work with 40000...
Mike has offered to "sneak in" a patch to the DTML for the local roles
assignment screen that simply uses a text field for the user name instead
of a select list, being as the current interface sucks to use even for much
smaller lists than 3000 users.
>It seems that way. Some problems GUF tried to solve (being able to
>seperate the role membership, authentication, valid domains and
>now user properties) have now been pushed down to the user object.
>The valid user list has been factored out into the UserSource.
>
>There exists a need for all of these functions to be pluggable.
In the latest version of the LoginManager (formerly UUF) code, the base
class for User objects delegates the getRoles, getDomains, and authenticate
methods back to its UserSource, allowing a GUF-like UserSource to work. I
haven't finished the GUS (Generic User Source) yet, but about all it lacks
right now is a little transformation code (that could be lifted from GUF)
and a proper Zope management interface.
>It would be nifty (but probably outside the scope of an initial release)
>if multiple components could be selected as sources for the userproperties.
>In this way I could have multiple property sheets from different sources
>(possibly readonly). There would have to be a property sheet called
'default'
>which is read/write for applications such as PTK which need a
>backend-independant method of storing properties.
I expect we'll make an initial release this week. I've already written
three LoginMethod classes (Basic Auth, REMOTE_USER, and Basic Cookie), and
if you like the LoginManager system overall, I imagine you might want to
create a TokenCookie LoginMethod class using code from GUF. :)
I still need to bone up on the propertysheets protocol in order to add it
in to the base User and UserSource classes, but I don't think it'll be too
difficult to define a delegation protocol for it. Creating a good way of
plugging propertysheet implementations into a UserSource, however, is going
to be a bit trickier, I think.
Ty and I are pretty excited about the project. I can't wait to transform
our custom user folders into UserSources and drop all the duplicated
validation code. Plus the idea of being able to later add a LoginMethod
for say, SSL client certificates, without having to change any UserSource
code, is just phenomenal. And getting property sheets to be available is
cool too. One of our folders is LDAP based and it would be just great to
put all the LDAP attributes on a property sheet, and provide editing, too.