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?