[Zope] hasRole bug or feature in 2.2.?

[Dieter Maurer]

Ron Bickers writes:
 > I think I understand, but correct me if I'm wrong.  The problem is that my
 > browser is not even *sending* the authentication information to the other
 > parts of the site until I first access a protected document at the root
 > level.  That is, the browser only continues to send auth info on levels at
 > and below where I've requested a protected document.  If that potected
 > document is at the root level, I get the auth info everywhere in the site.
 > Does this also mean that even after authenticating myself on one part of the
 > site, accessing a protected document on another part of the site may result
 > in an "unauthroized" response from Zope, to which my browser kindly responds
 > for me without me realizing it?
Yes, that may well be the case.

You may read RFC 2617 which describes HTTP authentication.
Browsers have a bit of freedom to decide when (and partially what)
authentication information they may send.

The spec allows them to automatically include authentication
information for requests into a subtree, when the root required
authorization. This is to efficiently handle the usual policy that
objects are not protected in isolation but usually whole
subtrees are protected.

 > If this is true, it explains clearly Zope's behavior.  It's really a browser
 > "feature" and not a Zope issue at all.
Right.

 > Given that, is it fair to say that I can never really be sure that an
 > authenticated user (somewhere else on the site) accessing an unprotected
 > document has a given role?  Or would it be safe to assume that after
 > accessing a root protected document, hasRole() will return the "right"
 > answer anywhere in the site?
You can not be sure. As said above, RFC 2617 lets browsers lots
of freedom about authentication information.
It suggests however (for efficiency reasons) that browsers
should behave as you hope for.

You get some more control, when you use cookie based authentication.
The cookie spec allows for the "path" parameter that instructs
the browser into what parts of the site the cookie
should be sent. As I know, Zope'e cookie based authentication
products define the cookie in such a way that it is sent to
the whole site.

This will not give complete safety (with respect to question),
as the browser may drop the cookie for various reasons
thereby effectively performing a log out.

 > If I can't safely assume any of the above, would I be better off using a
 > session product to track a user after log in so I can determine their roles
 > from an unprotected document?  Any other ways?
If the session product uses cookies, you will have a situation
similar to cookie based authentication. Otherwise, you
will need to shift the session id often between query string
and hidden variable which is a bit tedious.

 > My goal, BTW, is to avoid showing certain content on an otherwise public
 > page unless the authenticated user has the Member role.  If there is a
 > cleaner way to do this, I'm all ears.
If your users have trust in cookies (unlike me), I would
go for cookie based authentication.
Otherwise, I would place a "login" document in the root folder
and trust the browsers that they want to be efficient
and therefore send authentication information with all requests
to the site.



Dieter