[Zope-dev] New beta GenericUserFolder

Stuart 'Zen' Bishop zen@cs.rmit.edu.au
Tue, 23 Nov 1999 17:08:43 +1100 (EST)


On Mon, 22 Nov 1999, Ross Boylan wrote:

> I notice that a lot of products redefine class variables (e.g.,
> GenericUserFolder has
>     isPrincipiaFolderish=1
>     isAUserFolder=1
> ) which are already in the superclass.  Is this because:
> 	* it's more readable

Because it is more readable, and ensures that nothing wierd goes on
with multiple inheritance. For example, in GenericUserFolder,
I inherit from both Folder and BasicUserFolder. Now, since only BasicUserFolder
defined isAUserFolder, then I could have left it out and things would
work happily. However, if in a future revision, someone moved isAUserFolder
to SimpleItem or other subclass of Folder and defined it as false, my
product would break. I used to like multiple inheritance until I saw
a real product using it (Zope), and now I appreciate Java more :-)

> 1) Let new users define themselves on a new user screen (not a Zope
> management console).
> I've been hung up on the architectural points of where such a screen should
> go, how it is to refer to the acl_users folder, and how to set permissions.

You need a form, accessible to the Anonymous role, that will let a
user setup an account. You also need a DTML method to act as the
action of this form. This DTML method would insert the releveant data
into a TinyTable,SQL table, whatever. It would probably need a proxy
role defined so that the method has rights to add the data (since the
anonymous user shouldn't have rights). You could then use GenericUserFolder
to authenticate users from this TinyTable,SQL table,whatever.

[root]
    +- createAccount_form (DTML Method)
    +- createAccount_submit (DTML Method)
    +- secured
             +- acl_users (GenericUserFolder)
	                +- UserTable (TinyTable)
			+- userAuthenticate
			+- [ other GUF hooks]

createAccount_submit would be given a proxy role of Manager, and 
would insert a row into UserTable with all the relevant information
(username, sha.new(password).digest(), possibly roles).

userAuthenticate would generate sha.new(password).digest() and compare this 
to the stored SHA password hash in UserTable.

the other GUF hooks could calculate their return values, suck them out
of UserTable or just return fixed strings depending on your environment.

> 2) Have User objects which are subclasses of user, for extra data and
> functionality.
> I've been trying to avoid modifying the code in AccessControl/ directly,
> since that's cheating (and not robust against Zope system changes).
> 
> I think if you took the class as a variable, or took a factory object as an
> optional argument to your stuff, it would meet 2) without much trouble.

Its on my todo list, but it won't be there until I get the basics
released.

Similar functionality can be done right now. For example, I have
a DTML method userEmail high up in my tree which takes a username
and returns that users email address. It just means I have to
do userEmail(this(),REQUEST,username=AUTHENTICATED_USER.getUserName())
instead of AUTHENTICATED_USER.getEmail().

Note that your pluggable brain would have to be a subclass of
GenericUserFolder.User, and not AccessControl.BasicUser. The method
described in the previous paragraph could also work for users authenticated
through other mechanisms besides GenericUserFolder provided by DTML
code was intelligent enough.

-- 
 ___
   //     Zen (alias Stuart Bishop)     Work: zen@cs.rmit.edu.au
  // E N  Senior Systems Alchemist      Play: zen@shangri-la.dropbear.id.au
 //__     Computer Science, RMIT 	 WWW: http://www.cs.rmit.edu.au/~zen