[Zope] Zope 2.6.4: can't iterate through protected objects

[Kyler Laird]

[ 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