[Zope3-dev] Using classes as constants for security settings

Steve Alexander steve@cat-box.net
Sun, 17 Feb 2002 13:58:11 +0000


I've been playing around with various ways of getting symbolic constants 
that stay constant when you pickle and later unpickle them.

Here's what I've come up with. This works as a replacement for 
Zope/App/Security/Settings.py.

----
""" Security setting constants """

class PermissionSettingMetaClass(type):
     def __init__(self, name, bases, namespace):
         type.__init__(self, name, bases, namespace)
         self._name=name

     def __str__(self):
         return "PermissionSetting: %s" % self._name

     def _setDescription(self, description):
         self._description=description

     def getDescription(self):
         return self._description


class PermissionSetting(object):
     __metaclass__=PermissionSettingMetaClass
     def __init__(self):
         raise TypeError, "Cannot instantiate PermissionSettings"

# Explicit allow setting for permissions
class Allow(PermissionSetting): pass
Allow._setDescription("Explicit allow setting for permissions")

# Explicit deny setting for permissions
class Deny(PermissionSetting): pass

# Unset constant that denotes no setting for permission and role
class Unset(PermissionSetting): pass

# Explicit assign setting for roles
class Assign(PermissionSetting): pass

# Explicit remove setting for roles
class Remove(PermissionSetting): pass

----

I have tested this, and several variations.

There will only ever be one Allow class. The FQN of Allow is what gets 
stored with pickled objects.

However, we can add methods and descriptions to Allow, and other 
permissions, by creating methods in PermissionSettingMetaClass.

We can create __str__ and __repr__ methods on PermissionSettingMetaClass 
to make the individual permissions say something meaningful when printed.


The choice for Settings.py is now as follows:

   * Numbers for the values of Allow, Deny, Unset etc.

   * Strings for the values of Allow, Deny, Unset etc., and we always
     compare by equality, not identity

   * Classes as symbolic constants, as above. Comparing by identity is
     fine.

Any opinions?

--
Steve Alexander