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

[Stuart 'Zen' Bishop]

On Thu, 3 Feb 2000, Phillip J. Eby wrote:

> Understood.  Would it be possible though, to have a base mixin that can be
> added to other UserFolders, though?  Here's our (biggest) problems with GUF:
> 
> * GUF only does cookies *or* basic auth, and cannot handle both
> interchangeably.  (Compatibility with basic auth is important for ease of
> implenting authenticated XML-RPC calls, especially from Perl.)

It did in the final release version. If there is basic user authentication
data available, I decode and use it (assuming a cookie hasn't been passed).
Current problem: tokens are still generated, so the token cache bloats.
I have a patch for FTP from Chris Allen. A slight modification to his
patch should solve this issue for other access methods (which will
also have this problem - didn't think of it).

> * GUF uses a ticket-based authentication cookie, rather than a
> credential-based cookie.  This means that cookie logins cannot be scaled
> across processes or machines.  (Which is an issue for ZEO-based portals, as
> well as being an implementation issue for XML-RPC.)

On my internal todo list is to allow hooks to generate, store and retrieve
cookies for just this very reason :-) Storing the authentication tokens
in an external RDBMS would be nice as it will be preserved between Zope
restarts. Combine it with a RDBMSStorage instead of FileStorage and 
we should be able to have multiple Zope servers sharing the same
database.

Credentials are explicitly not stored in the cookie, as I have to
develop Intranet applications in a hostile environment.

> * GUF expects at certain points to load or iterate through the entire list
> of users.  We expect to be doing LDAP authentication against huge (hundreds
> of thousands at some point) databases, so this is entirely out of the
> question.

I think this issue has been solved. If the userExists hook is implemented,
the only time it iterates through the enrire list is when you ask it
to (you call acl_users.getUserNames or acl_users.getUsers). Its
also the reason there is no domain based authentication in there yet
(I currently have 3000 users, and have the requirement to scale to 40,000
within 2 years). 

> Memberfolder.validate() would walk the authenticators, passing the user
> source to each.  The authenticators could be as simple as just function
> objects which ask the user source to look something up based on the data in
> the request which they know how to parse.  Memberfolder would also delegate
> all user management functions to the user source, so that the "huge db"
> issues can be addressed.

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)

> If this architecture (or something like it) makes sense to you, I'd be
> willing to devote part of my time, (and nearly all of Ty's time :) ) to
> assisting with design and implementation.  And I don't mean spare time,
> either.  This is stuff we'd be working on at the *office*.  :)  Seriously,
> compatibility between the PTK member model and our authentication/scaling
> needs is mucho important for our projects.

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