[Zope] Re: Authentication problem -- worked around

[Jim Harrison]

Thanks for the response. I had been using a restricted access python script
or page template in the same folder with the document in question. The login
link in the documents calls the script on the current document, which pops
up the browser login window and then the script re-directs back to the
original document after authentication using context.page_url(). The links
on the document are supposed to change in response to the authentication
change by checking the user's wiki page editing privilege (this is a
standard security property) and hiding/showing appropriate links.

After moving the login script to the root folder, all pages in subfolders
behave perfectly in Safari -- thanks! However, the problem persists in IE 6
(Win) and Firefox 0.8 (Mac). The browser login window appears after clicking
the login link but the page links do not change after login and
re-direction. If I then type the name of the edit form page template, I can
edit the text of the page without additional login. When I save the edited
page, it now shows the correct list of links.

So it appears that once the page loads in these browsers, I can't get the
TAL code to execute again after the re-direct to cause the link list to
change. Reloading or jumping around between pages doesn't help. However,
either merely visiting the Zope management interface (no editing or other
changes) and returning to the page or editing the text of the page in the
editing template causes the code to execute and display the links correctly.
Since it appears the user is authenticated in the appropriate location, this
problem would seem more related to the browser failing to pull a new page
from the server. However, if I clear out the Firefox cache and cookies and
set the cache size to 0, the problem persists. Perhaps the browsers just
maintain the original copy of the page in RAM and don't recognize that an
updated version should be pulled from the server, so it's not strictly a
disk cache issue.

By the way, once the links change to reflect authentication, visiting the
management interface, logging out and returning to the page causes the links
to flip back to the non-authenticated state, so no problems there. It would
be of interest to know what the management interface does to force
everything to update. If I could do that in the login script, I'd be set.

In any case, the problem can be worked around by having the login script
return the rendered page content rather than a redirect. ZWiki has a render
method that can be used for this (return context.render(RESPONSE=RESPONSE)).
This forces processing of the page after login and gives the correct
display. A minor side effect is that the page URL now ends with "login", the
script name. This doesn't appear to cause any problems, even with relative
links in the page.

Thanks for your time and suggestions.

Jim Harrison
Univ. of Pittsburgh


> From: Dieter Maurer <dieter at handshake.de>
> Date: Tue, 10 Feb 2004 19:44:45 +0100
> To: Jim Harrison <jhrsn at pitt.edu>
> Cc: zope at zope.org
> Subject: Re: [Zope] Please help with authentication problem
> 
>> I thought I would authenticate the users by setting up a small protected
>> page template that would get called against the current page of the user
>> when the login link was clicked. The template would force a login and then
>> redirect back to the page the user started from.
>> 
>> When I do that, it does force a login and redirect, but the menus do not
>> change after the redirect. However, the user is logged in--if I try this
>> with a manager password, I can type "manage" against the site url and
>> immediately jump into the management interface without additional login.
> 
> Almost surely, you are hit by a special feature of the HTTP 1.x
> basic authentication (read the specification to learn about the details):
> 
> HTTP 1.x says that the browser should automatically sent authentication
> information into the subhierarchy that requested authentication.
> 
> Browsers following the spec closely will not automatically
> send authentication information for URLs outside of this
> subhierarchy.
> They will however reuse login information when an URL from
> outside the hierarchy sends an Authentication challenge.
> 
> This explains what you describe provided your "login" page
> does not lie in an ancestor folder of your page.
> 
> Put your "login" page in one of these folders (e.g. the "Root Folder")
> and see whether the behaviour goes away.