[Zope] etcUserFolder and multiple roles

[mcdonc@iqgroup.com]

Zope is about the best thing to come around since nail clippers, but it
is slowly driving me insane, nuts -- like.. daytrader.  This message is
about an etcUserFolder-based product.  We all know etcUserFolder isn't
a supported product.  But what the heck, might as well ask.  The worst
that can happen is that I don't get awarded my Zope "cool users" pledge
pin.

Situation:

I have a folder which does not acquire any of its parents permissions,
we'll call it "Private".  Private's parent is the root folder.

Within the root folder, I have placed an HTTP-basic-auth-driven
etcUserFolder containing two users, which retrieves its user
information from a file named "etcUsers".  We'll call the two users
defined within this file "testuser-privileged" and
"testuser-unprivileged."  When creating the etcUserFolder, I assigned a
default role to these users of "Normalusers."  I have granted to the
Normalusers role all permissions in the root directory.

Now, on to the Private folder.  I have placed within the Private folder
a different HTTP-basic-auth-driven etcUserFolder containing (by virtue
of its use of a different passwd-style file named "etcUsers-Private") a
single user "testuser-privileged."  Now, you'll note that this user's
name matches that of the one defined within Root's etcUserFolder.  This
user's password (as defined in the "etcUsers-Private" file) matches the
one given to the "testuser-privileged" account in the top-level
etcUserFolder product.

When creating the etcUserFolder in "Private", I assigned a default role
to these users of "Privateusers."  I have granted to the Privateusers
role all permissions in the Private directory.  The Private directory,
otherwise, has all acquired permissions revoked and none granted to
"Normaluser".

Being a rational sort of guy, and knowing that HTTP basic auth compares
the username and password on every browser-server transaction, I sort
of figured that Zope would cope with this sort of setup by re-comparing
the username and password when the user "testuser-privileged" switches
between the Root and Private folders and would adjust the user's role
and privileges accordingly when displaying elements and methods that
make up a page.  But this is not the case.  What happens is this:  when
testuser-privileged hits the root folder, and enters in his password he
can see index_html no problem.   However, when he tries to visit the
"Private" folder, Zope tries to re-authenticate him.  It pops up
another login request, and *even if he enters the correct password it
will not let him properly view the page*.

Now this in itself drove me completely *fruity* until I figured out
*why* it wouldn't show him the page.  It's trying to show him the
index_html of the Private directory.  That file is made up of DTML
containing the standard_html_header & footer tags, which are acquired
from DTML methods in the root folder.  Because he has presumably
"switched" roles from "Normalusers" to "Privateusers", and
"Privateusers" has no permissions to standard_html_header and
standard_html_footer, it does not allow him to see the page.  In other
words, it's not an authentication problem, it's a permissions problem.

It seems that once he authenticates to the Private folder, he's stuck
in the "Privateusers" role with no way out.  And because the
"Privateusers" role doesn't exist at the root folder, there's no way to
assign it privileges to view items at this level.

So its at this point that I have to admit I've been lying.  It's not
etcUserFolder that I've been using, it's a hacked-up etcUserFolder
(smbUserFolder) that authenticates "over the wire" from the Linux box
that this thing runs on to an NT domain.  But it's materially the same
as the etcUserFolder product, the roles logic hasn't changed (actually,
only nine lines or so of code are different from product-to-product,
and those are only the ones which actually go out to check if the login
is OK).  This shouldn't make a difference.

So far, you're probably saying, "That's nice, Chris, but what's your
point?"

The problem is this.  I *do not* want to maintain YAUAD (yet another
user authentication database).  I have one, we use it for everything,
it's NT domain-based, it works, people don't have to remember seventeen
different usernames and passwords thank you.  Therefore, I don't want
to use the normal "User Folder" product that ships with Zope.  I *do
not* want to move the site to NT and use the NTUserFolder Product
(which claims to handle multiple roles per-user), it defeats the
purpose of this project (which is to develop an intranet product that
does not run on NT but can use NT authentication).  I *do not* want to
maintain local roles on a per-object basis (although this sounds a
little more feasible, and could be done as a last resort) as long as I
had a clear strategy to be able to do it.

OK, I've realized now that I'm in way over my head here.  I'm not even
going to try to explain this problem any more, it's giving me a
headache.  Maybe I'm just doing it all wrong.

Can anyone lend me a hand with a strategy to use the etcUserFolder
product or similar to maintain nontrivial security requirements within
Zope?