Chris McDonough <chrism@zope.com> wrote:
So, the (somewhat suprising) morals of the story are:
- you needn't use InitializeClass on classes which inherit from a base class which has security assertions and has itself been run through InitializeClass if a) you don't add any methods to the subclass and b) you're willing to accept the base class' security assertions. Not suprising.
- You needn't declare security assertions on overriding methods of subclasses of security-aware base classes unless you want to change those assertions. Not suprising.
This is understandable given that the underlying implementation of security assertions is to set a getSubobjectLimit__roles__ attribute, which gets inherited by subclasses.
- It's always safe to run a class through InitializeClass even if it does not have security declarations of its own. Not suprising.
InitializeClass checks for an attribute itself having a __security_info__ attribute (security = ClassSecurityInfo() does that), interprets it (by calling security.apply(cls)), and removes it after having being done with it.
- If you declare differing security assertions in your subclass, you do not need to run the subclass through InitializeClass for those security assertions to have an effect. Why this is the case is still somewhat a mystery. Surprising.
I'm sort of stumped as to how the subclass' assertions are applied in the absence of InitializeClass! This is not what I expected, I would have thought that differing assertions would only be applied if InitializeClass was called on the subclass. There's some magic going on here that I don't understand.
The magic is that Persistent has a __class_init__ that calls InitializeClass for you. (This attribute is actually set by App.PersistentExtra, called from Globals.) __class_init__ is an ExtensionClass feature. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com