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@handshake.de> Date: Tue, 10 Feb 2004 19:44:45 +0100 To: Jim Harrison <jhrsn@pitt.edu> Cc: zope@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.