recently I noticed that methods for retrieving user roles are affected by the URL from which the user logged in using basic authentication (as opposed to the location of the user account). I don't see any authentication-related cookies at all from ZOPE, session or otherwise, just basic http authorization. the problem is this: if one authenticates at a location deeper than their user account, authorization should apply up to the level of the account. it does - any method requiring authorization is allowed to run between the point of login and the user account - but when I test with *any* of these routines between the point of login and the user account it shows only 'Anonymous' - not the expected roles. user.getRoles() _.SecurityGetUser().getRoles() user.has_role( roleName ) visiting /manage or any other objects which require authorization works between the user account and the point of login - in fact, after rendering an object which would prompt for authorization if the only role were *really* Anonymous the roles for that object and ones it contains are fixed and show the expected results with getRoles() and has_role(). this problem occurred with ZOPE 2.5.0 or 2.5.1, and IE 5.5 or NN 7.0 Grant K Rauscher GeeKieR Enterprises http://www.geekier.com/
Grant K Rauscher writes:
recently I noticed that methods for retrieving user roles are affected by the URL from which the user logged in using basic authentication (as opposed to the location of the user account).
This is how the HTTP 1/1 specification requires it to be. Your browser follows this spec.
I don't see any authentication-related cookies at all from ZOPE, session or otherwise, just basic http authorization. Apparently, you are using a user folder that uses basic authentication. There are user folders around that can (be configured to) use Cookie authentication. You can also use CookieCrumber for that.
Dieter
This is how the HTTP 1/1 specification requires it to be. Your browser follows this spec.
Dieter, I understand the HTTP spec... but ZOPE does not work that way. I can use methods which require roles above where I logged in. The methods used for returning the roles themselves do not correlate with ZOPE's own actions. Therefore ZOPE has an internal inconsistency regarding user authentication with basic HTTP authorization.
Apparently, you are using a user folder that uses basic authentication. There are user folders around that can (be configured to) use Cookie authentication. You can also use CookieCrumber for that.
yes, I've used one or two - but I'm concerned with remedying the default ZOPE authentication mechanism, which is broken
<dtml-call "REQUEST.set('roles',['Anonymous',])"> <dtml-if AUTHENTICATED_USER> <dtml-call "REQUEST.set('roles',AUTHENTICATED_USER.getRoles())"> </dtml-if>
Paul, thanks, but your suggestion isn't applicable since the result of AUTHENTICATED_USER.getRoles() is wrong. Grant K Rauscher GeeKieR Enterprises http://www.geekier.com/
Grant K Rauscher writes:
This is how the HTTP 1/1 specification requires it to be. Your browser follows this spec.
Dieter,
I understand the HTTP spec... but ZOPE does not work that way.
I can use methods which require roles above where I logged in. The methods used for returning the roles themselves do not correlate with ZOPE's own actions. Therefore ZOPE has an internal inconsistency regarding user authentication with basic HTTP authorization. I do not think so.
Zope authentication works as follows: Traverse to the object indicated by the URL. Look up the chain of visited nodes whether you find a user folder that can authenticate the user sufficiently to access *this* object. If no such user folder is found, return an "Unauthorized" HTTP response. This behaviour is documented and consistent. However, when you access a weakly protected object (e.g. one viewable by "Anonymous") then there is no need for authentication information in the request. When you ask in this object, who is the user, you may get "Anonymous". The HTTP 1/1 spec says: the browser should automatically send authentication information for pages beside and below one that required authentication. Therefore, you may get a user different from "Anomynous", i.e. when you access below the object requiring authentication. When you do not like this behaviour, you must either: * protect your objects stronger * ensure a login high in the hierarchy * leave basis authentication (and use e.g. cookie authentication). Dieter
On Sat, 9 Nov 2002, Grant K Rauscher wrote:
This is how the HTTP 1/1 specification requires it to be. Your browser follows this spec.
Dieter,
I understand the HTTP spec... but ZOPE does not work that way.
I can use methods which require roles above where I logged in. The methods used for returning the roles themselves do not correlate with ZOPE's own actions. Therefore ZOPE has an internal inconsistency regarding user authentication with basic HTTP authorization.
Zope has one security policy (you are authed from the user folder you appear in on down), but basic auth has a different one that requires that the browser only *send* the auth credentials at the folder you *log in at* and down. So if you've logged in at the "below" location, and subsequently visit a location between the user folder and the log in point, the *browser* will not *send* the auth credentials, so you are anonymous. If you then auth on that new (higher) page, the browser will start sending the auth credentials. --RDM PS: it seems to me that not all browsers obey this, or perhaps some send the auth for the higher level folders if challenged and if it works don't prompt the user.
participants (3)
-
Dieter Maurer -
Grant K Rauscher -
R. David Murray