[Zope-dev] New beta GenericUserFolder

[Stuart 'Zen' Bishop]

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