Bill Anderson bill@libc.org
Fri, 28 Jul 2000 18:12:05 -0600

"Dan L. Pierson" wrote:


>  > So I came up with an idea.  What we want to be able to do is have a set
>  > of "tools" at the base of the portal.  These tools would include:
>  >
>  >   - Membership database
>  >   - Workflow attribute access
>  >   - Discussion access
>  >
>  > The default membership database would be a thin layer on top of the
>  > acl_users object.  It could be replaced with a ZPatterns specialist
>  > that looks up users from any number of sources.
> What is the difference between this and the Membership product effort
> other than some minimal support for default acl_users membership?

IIUIC, this would gain you the ability to have a portal site that can auth against an
existing DB (SQL, LDAP, Radius, etc), and/or the portal specific users db (Persistent
ZODB, etc).

> <Confession>
> I suspect that supporting default acl_users for Portal membership is a
> poor idea.  I can't prove it, but somehow I'm more comfortable with
> site managers being defined in a separate area that Portal members
> have no access too.  Please feel free to convince me that I'm just
> being silly and paranoid here :-)
> </Confession>

Paranoid, yes; silly no.  
Feel better? :)

This sounds similiar to what I was/am pondering for one of my domains. Multiple
Memberships, that wil pass failures up the chain, when set to. THink of it like NIS on
Unix. Depending on how you set it, teh login mechanism looks at the NIS server, and then
fails to the local passwd file, or vica-versa (or other combos, you get the idea).


Do not meddle in the affairs of sysadmins, for they are easy to annoy,
and have the root password.