I've uploaded a new beta of GUF , which I've fixed the outstanding authentication issues. This has (hopefully temporary) introduced a new limitation where things will stuff up if you create a GUF (using cookie authentication) inside an area already protected with cookie authentcation. I'm fairly certain this problem is also in most other acl_users inplementations that use cookie authentication methods. Now for something wierd: I have a Zope installation that looks like the following: [Root] +- acl_users (UserFolder) +- CS +- acl_users (GenericUserFolder) +- Zen (Protected - just user 'zen' has permissions to it) +- index_html Now - its all working just fine in most situations. Now, I can happily access the URL http://myserver:8080/CS/Zen - login screen pops up, I enter username & password, and I get my index_html page. I can then also go to http://myserver:8080/CS/Zen/manage and see the management screen just dandy. In this case, the manage method populates the left and right frames with the following URL's: http://myserver:8080/CS/Zen/manage_menu http://myserver:8080/CS/Zen/manage_workspace The title is: <TITLE>Zen on http://wombat:8080/Test2/CS/Zen</TITLE> However, If I fire up the browser and go directly to http://myserver:8080/CS/Zen/manage, things start screwing up. I get the authentication screen, enter username & password, ok, and then the manage panes pop up but authentication to these protected resources never happens. The manage method is populating the left and right frames with the following URL's: http://myserver:8080/manage_menu http://myserver:8080/manage_workspace The title is: <TITLE>Zen on http://myserver:8080</TITLE> If you click 'cancel' on the BasicUser authentication dialog box that has popped up, you will end up with unauthentated tracebacks in both panes. However, sharp eyes will notice that the 'back' button is now available on your brower, which is strange since this is the first page we have visited. Clicking 'Back' brings you to a fully functional, correctly authentication management screen. Wierd - something must be sending a dodgy redirect. Which is odd, since it isn't my code as far as I'm aware. I'm at a loss to why this would be happening. Why should the manage method return differently depending on if the browser has previously visited a protected page or not? I can duplicate this on both 2.0.1 and 2.1beta2. I can't duplicate in an area not protected by a GUF, so I assume it is something wrong in my code. Since I don't actually *have* manage, manage_main or manage_menu functions (I'm inheriting from Folder), I'll further assume it is something I've left out that shouldn't have been. Any hints? My forehead hurts. -- ___ // 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