I have a class that inherits from RoleManager (via Folder). It defined additional roles, including 'Administrator'. I would like the Administrator to be able to view management screens and create objects of certain types, but not be able to delete or rename objects of certain types. I tried using a ClassSecurityInfo instance as follows (I've removed the copy/delete objects part for simplicity and am just focusing on the view management screens part) class Myfolder(Folder): """ The base folder for the product """ meta_type="Myfolder" __ac_roles__=('Manager', 'Administrator', 'Researcher', 'Reviewer') security = ClassSecurityInfo() security.declareObjectProtected() security.declareProtected('View management screens', 'manage') # ..snip my methods ... security.setPermissionDefault('View management screens',('Manager', 'Administrator')) But a user with just an Administrator role could not view the myfolder/manage screen I also tried using __ac__permissions__ class Myfolder(Folder): """ The base folder for the product """ meta_type="Myfolder" __ac_roles__=('Manager', 'Administrator', 'Researcher', 'Reviewer') __ac_permissions__= ( ('View management screens', ('manage','manage_main'), ('Manager', 'Administrator'), ), ) with the same result. In both cases if I visit the Security tab of that folder (as a Manager) none of the default check boxes for the various roles and permissions have been altered; ie, the one for "View Management Screens" still has "Acquire Permissions Settings" checked. My specific question is, what am I doing wrong? My more general question is what is the interplay between using ClassSecurityInfo and __ac__permissions__? Should both be set, or should the latter be used to handle everything? Thanks, John Hunter zope 2.7
"John" == John Hunter <jdhunter@ace.bsd.uchicago.edu> writes:
John> I have a class that inherits from RoleManager (via Folder). John> It defined additional roles, including 'Administrator'. I John> would like the Administrator to be able to view management John> screens and create objects of certain types, but not be able John> to delete or rename objects of certain types. A followup - I've learned a bit more and realized I made a mistake in the code I posted so I want to focus my question. Goal: allow authenticated users with Role 'Administrator' or 'Manager' to access the manage_main screen of my instance, but disallow non-authenticated users or users with other roles. I've learned that ClassSecurityInfo supersedes __ac_permissions__, so I'm focusing my energies here In the example below, RestrictedFolder derives from Folder Example 1: I can access manage_main w/o no passwd authentication. I want to be prompted for passwd and given access if user has role Administrator or Manager class Workflow(RestrictedFolder): """ The base folder """ meta_type="Workflow" __ac_roles__=('Manager', 'Administrator', 'Researcher', 'Reviewer') #permission = 'View management screens' permission = 'View' roles = ('Manager', 'Administrator') security = ClassSecurityInfo() security.setDefaultAccess('deny') def __init__(self, id=None): # snip pass security.setPermissionDefault(permission, roles) security.declareProtected(permission, 'manage_main') def manage_main(self, *args, **kwargs): 'does this need to be overridden to have security apply to it?' return RestrictedFolder.manage_main(self, *args, **kwargs) InitializeClass(Workflow) Example 2: a user with Role Administrator cannot access manage_main, the following error is produced (passwd is correct for this user) You are not authorized to access this resource. Username and password are not correct. (Also, an error occurred while attempting to render the standard error message.) In this example, the code is the same as above, but I've reversed the permission comment. That is, permission = 'View management screens' I am calling InitializeClass(RestrictedFolder). I am refreshing my product and restarting my browser with each test. Changing the default from 'deny' to 'allow' produces almost the same result (the only difference is in example 2 I don't get the part about the standard error message_ I'm clearly missing something fundamental. What? I've read and reread the Security sections of the ZDG and Zope Book, to no avail. Thanks! John Hunter zope-2.7
John Hunter wrote:
"John" == John Hunter <jdhunter@ace.bsd.uchicago.edu> writes:
John> I have a class that inherits from RoleManager (via Folder). John> It defined additional roles, including 'Administrator'. I John> would like the Administrator to be able to view management John> screens and create objects of certain types, but not be able John> to delete or rename objects of certain types.
A followup - I've learned a bit more and realized I made a mistake in the code I posted so I want to focus my question.
Goal: allow authenticated users with Role 'Administrator' or 'Manager' to access the manage_main screen of my instance, but disallow non-authenticated users or users with other roles.
I've learned that ClassSecurityInfo supersedes __ac_permissions__, so I'm focusing my energies here
In the example below, RestrictedFolder derives from Folder
Example 1: I can access manage_main w/o no passwd authentication. I want to be prompted for passwd and given access if user has role Administrator or Manager
class Workflow(RestrictedFolder): """ The base folder """ meta_type="Workflow"
__ac_roles__=('Manager', 'Administrator', 'Researcher', 'Reviewer')
#permission = 'View management screens' permission = 'View' roles = ('Manager', 'Administrator') security = ClassSecurityInfo() security.setDefaultAccess('deny')
def __init__(self, id=None): # snip pass
security.setPermissionDefault(permission, roles) security.declareProtected(permission, 'manage_main') def manage_main(self, *args, **kwargs): 'does this need to be overridden to have security apply to it?' return RestrictedFolder.manage_main(self, *args, **kwargs) InitializeClass(Workflow)
Example 2: a user with Role Administrator cannot access manage_main, the following error is produced (passwd is correct for this user)
You are not authorized to access this resource.
Username and password are not correct. (Also, an error occurred while attempting to render the standard error message.)
In this example, the code is the same as above, but I've reversed the permission comment. That is, permission = 'View management screens'
I am calling InitializeClass(RestrictedFolder). I am refreshing my product and restarting my browser with each test. Changing the default from 'deny' to 'allow' produces almost the same result (the only difference is in example 2 I don't get the part about the standard error message_
I'm clearly missing something fundamental. What?
You got the first part right and that is making security declarations on your class, but you still have to specify security on the folder instance by going to the security tab and giving 'Administrator' the required permissions or writing code that does this automatically when you create the folder. I think you are misunderstanding what __ac_roles__ mean - this only provides pre-defined role names. -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za
"Roch�" == Roch� Compaan <roche@upfrontsystems.co.za> writes:
Roch�> You got the first part right and that is making security Roch�> declarations on your class, but you still have to specify Roch�> security on the folder instance by going to the security Roch�> tab and giving 'Administrator' the required permissions or Roch�> writing code that does this automatically when you create Roch�> the folder. Essentially my question is - can I do this step in code and if so how? I have a lot of objects and roles and its not practical to manually set the default permissions for each role in the web interface each time a new instance of my product is created. Essentially I want to define these defaults in my product code. John Hunter
John Hunter wrote:
"Roché" == Roché Compaan <roche@upfrontsystems.co.za> writes:
Roché> You got the first part right and that is making security Roché> declarations on your class, but you still have to specify Roché> security on the folder instance by going to the security Roché> tab and giving 'Administrator' the required permissions or Roché> writing code that does this automatically when you create Roché> the folder.
Essentially my question is - can I do this step in code and if so how? I have a lot of objects and roles and its not practical to manually set the default permissions for each role in the web interface each time a new instance of my product is created. Essentially I want to define these defaults in my product code.
Yes, all classes subclassing RoleManager has a manage_permission method that can be used to change permissions. You could for instance put the following in manage_afterAdd of your class to give only Manager and Administrator the 'View' permission and prevent this permission from being acquired: roles = ['Manager', 'Administrator'] self.manage_permission('View', roles, acquire=0) Notice that permissions are set on the instance and if you change your security policy in future you will have to write an update script that fixes permissions on objects affected by the policy change. -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za
"Roch�" == Roch� Compaan <roche@upfrontsystems.co.za> writes: Roch�> Yes, all classes subclassing RoleManager has a Roch�> manage_permission method that can be used to change Roch�> permissions. You could for instance put the following in Roch�> manage_afterAdd of your class to give only Manager and Roch�> Administrator the 'View' permission and prevent this Roch�> permission from being acquired:
Well, that is the most helpful thing I have learned in days, and not just for this problem! I have been suffering from the fact that self in the __init__ function has not been wrapped by the acquisition wrapper, and have used all kinds of hacks in my code to deal with this. manage_afterAdd fixes them all. Thanks for your help, John Hunter
I'm updating to Zope 2.71 (from 2.61) and the gvib interbase adapter product is now broken. I have the latest version I could find (but its been compiled (pyd) for Python 2.1. I am running the Windows version. Anyone able to get gvib working with Zope 2.71? David
On 7 Jul 2004 at 10:07, David Hassalevris wrote:
I'm updating to Zope 2.71 (from 2.61) and the gvib interbase adapter product is now broken. I have the latest version I could find (but its been compiled (pyd) for Python 2.1. I am running the Windows version.
Anyone able to get gvib working with Zope 2.71?
You didn't say what version of Python you're using. Also, are you using Firebird 1.5 or something else? -- Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax http://www.wecanstopspam.org/ AOL-IM: BKClements
Hi Brad, The problems started with Zope 2.71 running Python 2.33. I think the module that imports the python dll (gvibase?) needs to be recompiled to request python2.3.3 not python2.1. I would do it myself but I dont have a c compiler, or SWIG or ... Ok, my dog ate my homework. David ----- Original Message ----- From: "Brad Clements" <bkc@murkworks.com> To: "Zope Users" <zope@zope.org> Sent: Thursday, July 08, 2004 2:01 PM Subject: Re: [Zope] gvib interbase adapter and Zope 2.7
On 7 Jul 2004 at 10:07, David Hassalevris wrote:
I'm updating to Zope 2.71 (from 2.61) and the gvib interbase adapter product is now broken. I have the latest version I could find (but its been compiled (pyd) for Python 2.1. I am running the Windows version.
Anyone able to get gvib working with Zope 2.71?
You didn't say what version of Python you're using. Also, are you using Firebird 1.5 or something else?
-- Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax http://www.wecanstopspam.org/ AOL-IM: BKClements
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
"Roch�" == Roch� Compaan <roche@upfrontsystems.co.za> writes:
Roch�> Yes, all classes subclassing RoleManager has a Roch�> manage_permission method that can be used to change Roch�> permissions. You could for instance put the following in Roch�> manage_afterAdd of your class to give only Manager and Roch�> Administrator the 'View' permission and prevent this Roch�> permission from being acquired: Next problem: I have a class (derived from folder) MyFolder that I am instantiating from the web interface. In the manage_afterAdd function of that class, I am instantiating several other objects (MyObject) that reside in MyFolder. These objects are not meant to be instantiated by users, and will only be instantiated by MyFolder when it created. I also want to set the default permissions and roles for MyObject. If I define manage_afterAdd in MyObject, the function is not called, presumably because I am not instantiating MyObject from the manager interface. In MyFolder.manage_afterAdd, I do o = MyObject(oid) self._setObject(oid, o)
From product code, is there a way to add a MyObject instance to MyFolder so that MyObject.manage_afterAdd(self, item, container) will be called with self properly wrapped to make the role manager manage_permissions calls?
Thanks again, John Hunter zope 2.7
John Hunter wrote:
I also want to set the default permissions and roles for MyObject. If I define manage_afterAdd in MyObject, the function is not called, presumably because I am not instantiating MyObject from the manager interface. In MyFolder.manage_afterAdd, I do
o = MyObject(oid) self._setObject(oid, o)
That doesn't make sense, because '_setObject' calls 'manage_afterAdd' on the wrapped object so it should work - see OFS/ObjectManager.py. -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za
"Roch�" == Roch� Compaan <roche@upfrontsystems.co.za> writes:
Roch�> That doesn't make sense, because '_setObject' calls Roch�> 'manage_afterAdd' on the wrapped object so it should work - Roch�> see OFS/ObjectManager.py. Of course you are right. I had first tried to add the object outside of a manage_afterAdd method and got a missing attribute error on the call to manage_permissions: Error Type: AttributeError Error Value: _getProductRegistryData I then moved the code into manage_afterAdd and still got the error message. Apparently, I had not successfully refreshed my product, because it is now working as advertised. Cheers, JDH
participants (4)
-
Brad Clements -
David Hassalevris -
John Hunter -
Roché Compaan