[Zope-PTK] Stability rule-of-thumb (fwd)

[Phillip J. Eby]

At 11:33 AM 2/4/00 +1100, Stuart 'Zen' Bishop wrote:
>
>If there is a way of registering which authenticator handles what
>functions, then it very closely resembles a suggestion I just made
>to Mike which effectivly turns GUF into your Memberfolder.
>
>I hadn't though of passing the entire REQUEST object to an authenticator -
>allowing this will solve my domain based authentication issue. 
>
>> To implement this, GUF would split in two - a set of standard
>> authenticators, and a pluggable user source.  (Although, a user source
>> could possibly consist simply of a folder, containing the appropriate
>> methods!)  Other existing UserFolders (such as the ones Ty and I have
>> written) would do a similar split.  The standard PTK Member Folder could
>> automatically include a set of standard authenticators when created, for
>> ease of setup.
>
>Hehe... 'a folder containing the appropriate methods' is quite an
>apt description of GUF in its present state. If you develop this, GUF can 
>be frozen and depricated provided the hooks are called using the DTML Method 
>calling conventions (context,REQUEST as the first two parameters)

Ty and I spent two hours on the phone with Mike, and together we came up
with a model for a "Universal User Folder" that we're going to try and
document Real Soon Now (like starting tomorrow).  The validation bits of
GUF could be recast as a validator, and the rest could pretty much go away.
 The model looks something like this:


UniversalUserFolder:

	* UUF has a validate() method which walks validators, asking each one for
a user object, given the request.  Each validator is given the request, and
something which implements a "getUser" method.  The validator returns a
user object and a priority value (which is used to distinguish between
anonymous-like and true logins), or None if it can't verify the identity of
the user.

	* UUF has a UserSource object which implements addUser, getUser, and
deleteUser as a minimum (although these methods may be null or raise
NotImplemented.)  The UserSource is passed to each validator so that the
validator can find users.

	* UUF is an objectManager, so arbitrary DTML or other methods can be added
to it.  This allows sensible placement of a variety of UI stuff (e.g. an
"add user" form, "member roster", "search users", etc.) as well as things
like SQL or LDAP connection objects.

	* has register/unregister methods for validators added into it to attach
themselves

	* is responsible for having a loginForm method, which will be called, not
raised as an error.  The method can and should use <dtml-raise> to
determine the type of error it will raise.  (There should probably also be
a method for telling somebody they don't have permission to do something,
even though they *are* logged in and a valid user.)


Validator:

	* has manage_afterAdd and manage_beforeDelete which call registerValidator
and unregisterValidator on the UUF.

	* has validate() method which strictly looks at the request for
authentication tokens (e.g. cookies) or login fields

	* has a "priority" value (distinct from the validate() return priority)
which is used by the UUF to set the query order for all the validators

	* has management screens and properties for any validator-specific
configuration (e.g. cookie timeouts, cookie names, etc.)


UserSource:
	* can be implemented as a plain folder that just has the get/etc. methods
in it, or as an ObjectManager ZClass.


Mike, Ty...  Did I miss anything?  I think there are some details not fully
nailed down above, but then, I think they're ones that we haven't actually
succeeded in nailing down yet.  :)