Re: [Zope] hasRole bug or feature in 2.2.?
Chris McDonough writes:
You didn't protect the isMember document. It's viewable by Anonymous. The Zope security machinery short-circuits authentication for resources that don't require it. This means that when you view a resource that's unprotected, you view it "as Anonymous". Anonymous doesn't have the Member role, so you see "You are NOT a Member" when you view /isMember.
I don't particularly like this behavior, but it seems not to bother anyone else. I think it should authorize you and set AUTHENTICATED_USER if you pass in auth info regardless of the protection on the resource you're trying to view. It would bother me a lot, if you were right :-)
Fortunately, you are not completely right. What really happens is the following: when ZPublisher has located the object addressed by the request URL, it starts going back its way along PARENTS to find a UserFolder that can authenticate a user with sufficient permissions to call the object. If the object is unprotected, then no permissions are required. In this case, the top level UserFolder will return "Anonymous", if it is reached and it cannot authenticate the user. Therefore, an unprotected object can be called by Anonymous and in this case, "hasRole" is that of "Anonymous", as Chris reported. However, if previously a protected object has been accessed, then your browser may (and usually will) send Authentication information with all following requests. A UserFolder will use this information (if present) to authenticate the user, even if no permissions are necessary for object access. If successful, AUTHENTICATED_USER will not be "Anonymous" even though the accessed object is unprotected. Dieter
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Dieter Maurer Sent: Friday, January 12, 2001 5:00 PM To: Chris McDonough Cc: zope@zope.org Subject: Re: [Zope] hasRole bug or feature in 2.2.?
However, if previously a protected object has been accessed, then your browser may (and usually will) send Authentication information with all following requests. A UserFolder will use this information (if present) to authenticate the user, even if no permissions are necessary for object access. If successful, AUTHENTICATED_USER will not be "Anonymous" even though the accessed object is unprotected.
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? If this is true, it explains clearly Zope's behavior. It's really a browser "feature" and not a Zope issue at all. 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? 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? 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. Thanks! _______________________ Ron Bickers Logic Etc, Inc. rbickers@logicetc.com
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
Thank god for Dieter. :-) I'll trust that you're right, Dieter, because reading the traversal machinery code makes my head hurt. :-) ----- Original Message ----- From: "Dieter Maurer" <dieter@handshake.de> To: "Chris McDonough" <chrism@digicool.com> Cc: <zope@zope.org> Sent: Friday, January 12, 2001 5:00 PM Subject: Re: [Zope] hasRole bug or feature in 2.2.?
Chris McDonough writes:
You didn't protect the isMember document. It's viewable by Anonymous. The Zope security machinery short-circuits authentication for resources that don't require it. This means that when you view a resource that's unprotected, you view it "as Anonymous". Anonymous doesn't have the Member role, so you see "You are NOT a Member" when you view /isMember.
I don't particularly like this behavior, but it seems not to bother anyone else. I think it should authorize you and set AUTHENTICATED_USER if you pass in auth info regardless of the protection on the resource you're trying to view. It would bother me a lot, if you were right :-)
Fortunately, you are not completely right.
What really happens is the following:
when ZPublisher has located the object addressed by the request URL, it starts going back its way along PARENTS to find a UserFolder that can authenticate a user with sufficient permissions to call the object.
If the object is unprotected, then no permissions are required. In this case, the top level UserFolder will return "Anonymous", if it is reached and it cannot authenticate the user. Therefore, an unprotected object can be called by Anonymous and in this case, "hasRole" is that of "Anonymous", as Chris reported.
However, if previously a protected object has been accessed, then your browser may (and usually will) send Authentication information with all following requests. A UserFolder will use this information (if present) to authenticate the user, even if no permissions are necessary for object access. If successful, AUTHENTICATED_USER will not be "Anonymous" even though the accessed object is unprotected.
Dieter
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
participants (4)
-
Chris McDonough -
Chris Withers -
Dieter Maurer -
Ron Bickers