Description: (I posted this to zope-dev, but havent seen an answer yet. Im adding it here so it doesnt get forgotten)
some questions raised by http://www.zope.org/Documentation/How-To/ProductAuthorUpdateGuide
Firstly, how does the presence of __allow_access_to_unprotected_subobjects__=1 in a class affect access to attributes in derived classes? Does it affect the whole instance, or just attributes of the class that includes it. In the following example I know subobject_2 is accessible, but what about the others? <example snipped>
Toby, (sorry not to get back to you earlier on this) The security assertion is generally tested on instances, so if an instance has the assertion in its class (or any of its base classes) then it is effective for all of the base classes of that object.
Secondly, I am confused that there have not been any security changes in ObjectManager.py and PropertyManager.py. As I understand it, the subobjects that they manage (ie properties and folder items) now fall into the inaccessible-by-default category. What am I missing?
Actually there has been a change: the security assertion is in SimpleItem.Item (which acts as a base class for most, but not all, Zope objects). This is why "dynamic" attributes such as properties continue to work as before. Your first reaction might be (as mine was) "well, doesn't that just put us right back where we were before?". Not quite. What has been done is a first step to changing the policy to deny- by-default rather than allow-by-default. Having the assertion in the Item class has the effect of: o allowing access to properties and some other kinds of attributes that are not currently explicitly protected, needed for backward compatibility o DISallowing access to certain other things that the old security rules would have allowed - for example under the old rules alone it was possible to get to the func_globals and other attributes of methods that you really shouldn't have access to. We had to handle that with special cases, which was painful and error prone (and only worked for problems that you knew about). The new policy with the security assertion allows us to keep access to properties and things we _need_ access to for backward compatibility, but also has the effect of protecting things like method attributes and other (possibly unknown) bits that should be off limits (a method would need a security assertion of its own for those things to be accessible). While this is not totally perfect and still requires you to be careful about protecting attributes of base classes, it is better than it was before and a first step on the road to where we want to be that shouldn't cause too much angst among users and product developers. Hope this helps - I'm going to reformat this a little and add it to the Product author guide. Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com