[ http://mail.zope.org/pipermail/zope/2004-March/147995.html ] Bakhtiar A Hamid wrote:
there were some major security changes in zope starting zope2.63 and the beta3(?) of zope 2.7.0
Ug. I'm all for better security models but this one seems like it has no benefit. I decided to install a test instance of 2.7.0 to discover if this behavior continues. (I haven't done a manual install for a loooong time. It's gotten *much* easier.) It does. Instead of doing something obvious like this, for object in container.objectValues(): try: print object.title except: continue I apparently have to use a kludge like this. for object_id in container.objectIds(): try: object = container[object_id] except: continue print object.title This gets even uglier because I usually get a list of objects and then sort them on some attribute. Here's my kludge around this problem. def safe_objects(objects): safe_objects = [] for i in range(len(objects)): try: safe_objects.append(objects[i]) except: None return(safe_objects) objects = safe_objects(context.objectValues()) It looks like I'll be adding this code to a lot of scripts so I'll sure appreciate suggestions for improvements. Unfortunately it doesn't support the situation where I want to give special handling to an object for which the (perhaps not-yet -authenticated) user doesn't have sufficient permissions for the object. Here's some handling for that. for item in container.objectItems(): id = item[0] try: object = item[1] except: object = None Hmmm...it would be nice to be able to define an "except" clause for "for".
check out the Changes.
While you wouldn't guess it from looking at the 2.6.3 page http://zope.org/Products/Zope/2.6.3/ there *is* a change log for 2.6.3. http://zope.org/Products/Zope/2.6.3/CHANGES.txt (Go to the 2.6.4 change log and change the URL to "2.6.3".) It contains a mention of iterators. Iteration over sequences could in some cases fail to check access to an object obtained from the sequence. Subsequent checks (such as for attributes access) of such an object would still be performed, but it should not have been possible to obtain the object in the first place. The "fix" does not seem to provide what this change describes. objectValues() *does* provide objects that "it should not have been possible to obtain" but now it raises an exception if an iterator assigns them. They could still, I assume, be passed to methods that fail to check object permissions. I don't see the value. --kyler