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/
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