[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.