Hi all, I was tracking down a weird but very repeatable "IOError 5" bug which still baffles me, but it led me to a section of code where I have used "hasRole()" to find out if a user is supposed to be able to manage a particular object. For whatever reason the bug didn't show up until I switched to 2.5.1 (From 2.4.3). Reading the Zope source, I found a deprecation warning on this method, but rather confusing suggestions as to what to use instead. I also found a note about it on zope.org which mentions yet another method. So I was wondering if anyone could tell me what the significant differences are between the following options: allowed has_role has_permission (the last is mentioned on the zope.org site, though I didn't see it in the source (as yet)). They all seem pretty much the same to me, though there are minor API differences, and a hint that they represent different security models. (e.g. what's an "object role"? Not the same as "local role" I would guess?). Note that this is in Zope 2.5.1 and I'm migrating from 2.4.3. I've called _.SecurityGetUser() to get my user (not sure why this is safer than AUTHENTICATED_USER, but I am told that it is). Then I'm asking whether that user is supposed to be able to see the "Edit" button on my page. If they have a local role of "Moderator", they should. Thanks, Terry -- ------------------------------------------------------ Terry Hancock hancock@anansispaceworks.com Anansi Spaceworks http://www.anansispaceworks.com P.O. Box 60583 Pasadena, CA 91116-6583 ------------------------------------------------------
Sorry to reply to myself ;-D, but... Terry Hancock wrote:
So I was wondering if anyone could tell me what the significant differences are between the following options:
allowed has_role has_permission
Looks like has_permission was a good choice -- I just tried it. Interestingly, the IOError bug went away. I find that very strange considering that that module doesn't obviously do any I/O (but I guess it must). I'm still curious what the others are for, though. Terry -- ------------------------------------------------------ Terry Hancock hancock@anansispaceworks.com Anansi Spaceworks http://www.anansispaceworks.com P.O. Box 60583 Pasadena, CA 91116-6583 ------------------------------------------------------
Looks like has_permission was a good choice -- I just tried it. Interestingly, the IOError bug went away. I find that very strange considering that that module doesn't obviously do any I/O (but I guess it must).
That's because, when you used hasRole, it was trying to output its warning (probably to the console), and failed with an IOError. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
Florent Guillaume wrote:
Looks like has_permission was a good choice -- I just tried it. Interestingly, the IOError bug went away. I find that very strange considering that that module doesn't obviously do any I/O (but I guess it must).
That's because, when you used hasRole, it was trying to output its warning (probably to the console), and failed with an IOError.
That makes sense. I suppose I need to use >> /dev/null to avoid this kind of thing in production use (though in this case, the warning did its job -- I removed the deprecated call). Cheers, Terry -- ------------------------------------------------------ Terry Hancock hancock@anansispaceworks.com Anansi Spaceworks http://www.anansispaceworks.com P.O. Box 60583 Pasadena, CA 91116-6583 ------------------------------------------------------
participants (2)
-
Florent Guillaume -
Terry Hancock