Hi, I've a question regarding security in Zope Product classes for Zope 2.6.1. I'm hoping that someone has some experience/suggestions for implementing Zope scurity within a product's class. I need to provide secure access to specific methods and attributes (e.g. meta_type) for a class within my Zope product. I have a set of specific roles that I need to create when an instance of my product is created along with the default roles of 'Manager' and 'Owner'. I am declaring this set of roles by assigning them to the __roles__ attribute: __ac_roles__= ( 'Anonymous', 'Authenticated', 'Manager', 'Owner', 'Editor' ) I've noted two different methods for declaring security in a class. The first is to use __ac_permissions__ to declare a tuple of tuples that declares a permission name, a tuple of method names, and a list of roles. For example: __ac_permissions__ = ( ('View', ('manage', 'manage_menu'), ['Manager', 'Editor']) ) The second method, which I believe to be the most recent, is to: 1. Declare the security object: security = AccessControl.ClassSecurityInfo() 2. Set the default security access to 'deny': security.setDefaultAccess('deny') 3. Declare each permission: security.setPermissionDefault( 'View', ['Authenticated', 'Manager', 'Editor']) 4. Assert that each method or subobject is protected by a particular permission: security.declareProtected( 'View', 'manage_menu') 5. Initialize the the class' security: InitializeClass(MyClass) The first method seems to work, although I have not tested to ensure that all of the methods inherited from the parent classes are protected. I have a sneaking suspicion that this is an older mechanism for Zope security. The second method seems to be the newest and most logical approach. The being exception that the default security access to 'deny' does not permit me to access attributes from my class that are basic Python types such as strings (e.g. meta_type from a DTML Method). I could declare the default security access to 'allow', but that seems inherently dangerous from a security standpoint. Thanks, Michael -- Michael R. Schwab