[Keeping most of this thread in tact since it's almost a howto on zope permissions - comments inserted below]
Consider a product MyProduct :
/MyProduct /MyClass /index_html /method2 /MyClass_add_permission /MyClass_factory /MyClass_add /MyClass_addForm
To add permissions to let method2 change properties : 1) add a Zope Permission to the MyProduct folder. Let's call it "MyPermission" 2) go to MyClass and click on the "Permissions" tab. 3) select "MyPermission" from the multiple select list. This is saying 'any instances of this product have the permission MyPermission'. This seems to be very much like a role.
I think it is more like saying "this permission is relevant to this ZClass".
4) go to MyClass and then click on the "Define permissions" tab. 5) opposite the "Manage Properties" label, select the "MyPermission" ie. allow any instances of the class to manage the properties.
However, I seem to have missed something since nowhere did we specify *who* has this permission. (eg. anonymous users, or just managers.). Damn, I feel dense.
Not at all... What you've done to this point is create a permission, and tell Zope that the user must have that particular permission in order to manage the properties. Here's the next part:
6) Go to the Zope root and look at the Security tab. From there, you can define which roles have "MyPermission" set.
Aaaahhh, <click>, gotcha ! Relief :)
*Now* Zope knows that a user must belong to one of the roles that has "MyPermission" set in order to manage properties.
Yep, now I'm on the same page.
Actually, I'd have really liked it if there were a security tab on the zclass (not the instance) - but I notice that there are no security tabs there.... only these wonderful "define permission" pages. Wait, perhaps that's a clue - why *aren't* there "security" tabs in zclasses ? I mean, for something as simple as setting "anonymous user can manage properties", a standard security tab would have done the job fine.
I think the idea is that security is more of an "instance" related thing. At the class level, you define which permissions are necessary to take given actions. In the actual instances, you define which roles have those permissions. (And the roles->permissions mapping is something that can be acquired). This is basically how the standard Zope objects work, and the ZClasses are consistent with that.
Now that I see the above, it makes more sense. It's essential to understand this thoroughly when creating products though. Up till now I've been wondering whether any of my products have lax privileges or expose holes (even though I'm sure Zope takes the common approach of 'closed by default, open explicitly').
Half way .... and your help is much appreciated.
Do you remember at school there was that annoying kid who stuck his hand up, asked a question, the teacher replied, yet still he didn't understand ? I'm that kid :)
Nahh.. I kinda felt like I had given a halfway sort of answer. But, I wasn't certain where to take it next...
Thanks for bearing with me on this one Kevin. Very much appreciated. When the Zope MVP awards come around, you've got my vote (for this, KmNews and much more) ! :) chas ps. renamed the subject title for the sake of the woeful archiving mechanism - hopefully it'll save somebody else going through the pain.