RE: [Zope] hasRole bug or feature in 2.2.?
Dieter writes:
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.
One relatively less tedious way to do this would be to put the session
id in the URL rather than in forms; you can do this by using an access
rule along the lines of:
dtml-let stack="REQUEST['TraversalRequestNameStack']"
dtml-if "(stack and stack[0][:6]!='manage')"
(assuming the next component of the path is the session id,
remove it from the traversal path)
dtml-call "REQUEST.set('session_id',stack.pop())"
(somehow make sure that the session_id is valid and revive the
session object. With SQLSession, may be done by
dtml-call "Session(session_id)"
(path in the next line is supposed to be replaced by something
which, preferebly dynamically, retrieves the path traversed up
to this point. This is needed so the session id shows up in
URLs generated down the tree)
dtml-call "REQUEST.setVirtualRoot(path+'/'+session_id)
/dtml-if
/dtml-let
What this does is translate a url of the form
http://server.com/123456/real/path
to http://server.com/real/path for resource-search purposes, while
making sure that all calls to absolute_url() return urls of the form
http://server.com/123456/... . This means that as long as you rely
on absolute_url rather than relative links, you're essentially done.
This ignores session initialization first time, but I hope the
general idea of how to do this is enough. I don't have a live
example at my fingertips, but something a lot like this was done
here some time ago.
Have fun,
Shai.
___
Zope maillist - [EMAIL PROTECTED]
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 )
Re: [Zope] hasRole bug or feature in 2.2.?
Chris McDonough wrote: I'll trust that you're right, Dieter, because reading the traversal machinery code makes my head hurt. :-) Likewise... I'm sure that's not a good thing ;-) cheers, Chris ___ Zope maillist - [EMAIL PROTECTED] 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 )
RE: [Zope] hasRole bug or feature in 2.2.?
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 ___ Zope maillist - [EMAIL PROTECTED] 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 )
Re: [Zope] hasRole bug or feature in 2.2.?
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" [EMAIL PROTECTED] To: "Chris McDonough" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] 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 - [EMAIL PROTECTED] 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 ) ___ Zope maillist - [EMAIL PROTECTED] 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 )
RE: [Zope] hasRole bug or feature in 2.2.?
From: Ron Bickers [mailto:[EMAIL PROTECTED]]
If this is true, it explains clearly Zope's behavior. It's really a
browser
"feature" and not a Zope issue at all.
Yes, that's the problem.
My solution is to use a custom UserFolder, which sets a temporary cookie
when a normal HTTP login is accepted. This cookie is then used for
further validation. The class I use is rather complex, providing
persistent login in addition to these features, and randomly re-creating
the cookie so one can't easily spoof a user, but this simple class will
get you going:
class UserFolder(AccessControl.User.BasicUserFolder):
def validate(self, request, auth='', roles=None):
user = AccessControl.User.BasicUserFolder.validate(self,
request, auth, roles)
if user is AccessControl.User.nobody or user is None:
if request.cookies.has_key('login'):
user =
self.getUser(request.cookies['login'])
else:
request.response.setCookie('login',
user.getUserName(), path='/')
return user
-Randy
___
Zope maillist - [EMAIL PROTECTED]
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 )
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 - [EMAIL PROTECTED] 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 )
RE: [Zope] hasRole bug or feature in 2.2.?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dieter Maurer Sent: Friday, January 12, 2001 5:00 PM To: Chris McDonough Cc: [EMAIL PROTECTED] 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. [EMAIL PROTECTED] ___ Zope maillist - [EMAIL PROTECTED] 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 )
Re: [Zope] hasRole bug or feature in 2.2.?
You're gonna laugh. Get ready. 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. - Original Message - From: "Ron Bickers" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 11, 2001 5:01 PM Subject: [Zope] hasRole bug or feature in 2.2.? I'm having a problem with AUTHENTICATED_USER.hasRole() I have a user with the role 'Member' defined at the root level (and nowhere else). I also have the following DTML method at the root level: dtml-if "REQUEST['AUTHENTICATED_USER'].hasRole(PARENTS[-1], ['Member'])" You are a Member. dtml-else Your are NOT a Member. /dtml-if When I first request the protected document /Bogus/membersonly, I'm prompted to log in. When I do, I get access to the /Bogus/membersonly document. Then when I request /Bogus/isMember, it says I am a Member. However, when I request /isMember, it says I am NOT a Member. Anywhere I request isMember, other than in the /Bogus folder, I am NOT a Member, even though the user is defined at the root level with the Member role. If I then request a protected document /membersonly, it shows me the document without prompt. After I do that, when I request /isMember or /AnyFolder/isMember, it now tells me I am a Member. Why does it not recognize that I'm a user with the Member role anywhere on the site until I access a protected document at the root level? Is this by design or a bug? If by design, what's the reasoning? Thanks! ___ Ron Bickers Logic Etc, Inc. [EMAIL PROTECTED] ___ Zope maillist - [EMAIL PROTECTED] 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 ) ___ Zope maillist - [EMAIL PROTECTED] 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 )
RE: [Zope] hasRole bug or feature in 2.2.?
-Original Message- From: Chris McDonough [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 11, 2001 6:25 PM To: Ron Bickers; [EMAIL PROTECTED] Subject: Re: [Zope] hasRole bug or feature in 2.2.? You're gonna laugh. Get ready. 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'm not sure this makes sense. If I protect isMember, then anonymous won't be able to determine if they're a member without being prompted to log in. Isn't that true? That's not what I want. Also, why does it behave differently after I view a protected document in the root? isMember is still not protected, but it then correctly returns that I have the Member role anywhere in the site. ___ Ron Bickers Logic Etc, Inc. [EMAIL PROTECTED] ___ Zope maillist - [EMAIL PROTECTED] 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 )
