Environment: Red Hat Linux/Intel, Zope 2.1.6, GenericUserFolder 1.1.0 Problem: I have a GenericUserFolder in a folder in the root folder. When I log in to the initial Zope management screen, with a user with both Manager and Owner roles (andy), I get this as debugging output: 2000-03-29T21:23:04 PROBLEM(100) GUF gudid is Even though I am not going into the folder with the GUF. Probably this is due to just accessing contents information. Note that it says "gudid" and not "gufid", which is what's in the code, which is a bit odd. It's also printing some squirrely 8-bit character that doesn't paste in. The folder with the GUF (XXX) has acquisition turned off for all permissions, and all permissions enabled on Manager. The GUF itself has normal security. In addtion to this, the user is assigned the local roles of Manager and Owner in both XXX and XXX/acl_users. It doesn't seem to matter whether these local roles are assigned or not. If, as my user with Manager and Owner roles, I try to get into XXX, this happens in the debug log: 2000-03-29T21:23:26 PROBLEM(100) GUF URL is http://stan:8080/XXX in validate ------ 2000-03-29T21:23:26 PROBLEM(100) GUF Failed to authenticate with http://stan:8080/XXX/acl_users - crawling up ------ 2000-03-29T21:23:26 PROBLEM(100) GUF Authenticated andy with http://stan:8080/acl_users ------ 2000-03-29T21:23:26 PROBLEM(100) GUF Returning andy from http://stan:8080/XXX/acl_users validate (roles=('Anonymous',)) ------ 2000-03-29T21:23:26 PROBLEM(100) GUF URL is http://stan:8080/XXX in validate ------ 2000-03-29T21:23:26 PROBLEM(100) GUF Failed to authenticate with http://stan:8080/XXX/acl_users - crawling up ------ 2000-03-29T21:23:26 PROBLEM(100) GUF Failed Authentication with http://stan:8080/acl_users ------ The first three messages seem okay to me. The problem is that it is only validating my user for the Anonymous role, and from then it seems to be working as it should: It pops up a login document. The login stuff and authentication seems to work properly. But it is not getting the correct Roles from the top-level acl_users. The superuser works as you would expect, until you look at the debugging info. 2000-03-29T21:47:14 PROBLEM(100) GUF URL is http://stan:8080/XXX in validate ------ 2000-03-29T21:47:14 PROBLEM(100) GUF Failed to authenticate with http://stan:8080/Starbase/acl_users - crawling up ------ 2000-03-29T21:47:14 PROBLEM(100) GUF Authenticated superuser with http://stan:8080/acl_users ------ 2000-03-29T21:47:14 PROBLEM(100) GUF Returning superuser from http://stan:8080/Starbase/acl_users validate (roles=('Anonymous',)) ------ 2000-03-29T21:47:14 PROBLEM(100) GUF URL is http://stan:8080/XXX in validate ------ 2000-03-29T21:47:14 PROBLEM(100) GUF Failed to authenticate with http://stan:8080/XXX/acl_users - crawling up ------ 2000-03-29T21:47:14 PROBLEM(100) GUF Authenticated superuser with http://stan:8080/acl_users ------ 2000-03-29T21:47:14 PROBLEM(100) GUF Returning superuser from http://stan:8080/XXX/acl_users validate (roles=['Manager', 'Admin', 'Engineer', 'Manager', 'User']) The difference here is on the first try (with andy), it crawls up twice and fails each time, but with the superuser, it again crawls up twice (gets just the Anonymous role at first), but on the second crawl, validates the correct roles (note that manager appears twice). Tracebacks dont look useful, just raising the LoginRequired exception, and the only reason I have a traceback is because of debug mode. Is this a bug (whose bug is it, anyway?) or a feature? (BTW, that's a Python XXX, not a porno XXX. So don't flood the box looking for pix of hot naked teen action. You won't even find any hot Python action yet.) -- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d "Therefore, sweet knights, if you may doubt your strength or courage, come no further, for death awaits you all, with nasty, big, pointy teeth!"
On Wed, 29 Mar 2000, Andy Dustman wrote:
2000-03-29T21:23:04 PROBLEM(100) GUF gudid is
A GUF object has just been instantiated. The squirrely character needs to be unique and is used as a key in the cookie cache. Junk debug message basically.
The first three messages seem okay to me. The problem is that it is only validating my user for the Anonymous role, and from then it seems to be working as it should: It pops up a login document. The login stuff and authentication seems to work properly. But it is not getting the correct Roles from the top-level acl_users. The superuser works as you would expect, until you look at the debugging info.
Its a bug. I'm putting together a patch release as we speak, and I hope to have this fixed (next on my list). I was hoping that the 2.1.6 release would make all this crawling-up-the-tree business unnecessary but the change proposed doesn't seem to have been implemented. (see http://lists.zope.org/pipermail/zope-dev/2000-January/002940.html ) I vaguely remember that the LoginManager for the PTK was going to make use of this, but I havn't had time to pay attention for the last month or so :-(
The difference here is on the first try (with andy), it crawls up twice and fails each time, but with the superuser, it again crawls up twice (gets just the Anonymous role at first), but on the second crawl, validates the correct roles (note that manager appears twice).
The Anonymous role being returned the first time is a recursion check kicking in - during the authentication stage, we need to access your methods in the GUF, which kicks in the authentication system again...
Is this a bug (whose bug is it, anyway?) or a feature?
My bug. -- ___ // 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
participants (2)
-
Andy Dustman -
Stuart 'Zen' Bishop