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

[Phillip J. Eby]

At 01:46 PM 2/3/00 -0500, Mike Pelletier wrote:
>On Thu, 3 Feb 2000, Phillip J. Eby wrote:
>
>    Well, this is what I'm presently evaluating.  I _am_ leaning towards
>using GUF as the basis of the membership objects.  I'm talking to Stuart
>Bishop right now about extending GUF in ways needed by PTK (user add
>interface, persistent propertysheets, back end manager).  These would
>hopefully become standard GUF services (though all GUF-plugins may not
>support these new features).

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

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

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

In short, GUF has a variety of built-in policy assumptions that won't work
for larger systems.  That's why I'd prefer a simple base class.  Or, better
yet, a scheme something like this:

Memberfolder contains:
	* collection of "authenticator" objects
	* "user source" object

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.

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.

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.