[Zope] AUTHENTICATED_USER reverts back to Anonymous User

Richard Barrett R.Barrett@ftel.co.uk
Fri, 30 Nov 2001 15:54:56 +0000


At 15:33 30/11/2001 +0200, Etienne Labuschagne <ELabuschagne@gims.com> wrote:
>Hi there,
>
>This is what happens
>
>1) User enters site (REQUEST.AUTHENTICATED_USER == "Anonymous User")
>2) User logs in when accesing a "secure" page. (REQUEST.AUTHENTICATED_USER 
>== "myUser")
>3) User goes to page that is available for Anonymous Users but which is 
>rendered differently for logged in users.  Page must now render as if user 
>is logged in, but does not because REQUEST.AUTHENTICATED_USER == 
>"Anonymous User" again??
>
>After doing some reading it seems as if this is a problem with the way 
>HTML authentication works (Zope does not receive a browser authentication 
>challenge or something like that).  Is there a way around this other than 
>using cookies or url mangling?
>
>Thanks
>Etienne

You are correct in concluding that you are observing the consequences of 
how HTTP's Basic Authentication mechanism is supposed to work. The relevant 
RFC2617 says:

"A client SHOULD assume that all paths at or deeper than the depth of the 
last symbolic element in the path field of the Request-URI also are within 
the protection space specified by the Basic realm value of the current 
challenge. A client MAY preemptively send the corresponding Authorization 
header with requests for resources in that space without receipt of another 
challenge from the server."

Howover, browsers are not obliged to (and some popular browsers such as IE5 
do not) volunteer authentication credentials but re-present the request 
with the credentials if the server issues an HTTP 401 response challenge 
for authentication.

When your user makes a request with a URL outside the sub-tree protected by 
a previous authentication challenge the browser, quite rightly, does not 
submit the credentials for an unrelated URL. This decision is fully 
justified given that Zope doesn't then challenge for credentials if they 
aren't supplied.

Using cookies may be your best solution as you can challenge for the cookie 
at one level in your sites URL hierarchy but stipulate the 'path' attribute 
of the cookie so that it is returned for accesses from any point in URL 
hierarchy. I'm not a user myself but presumably the CookieCrumbler Product 
may be of use here.