brinegar at ecn
Mar 16, 2010, 1:07 PM
Post #5 of 5
You've just made my week! I'm glad that my failure to understand how all
of this works has shed some light on the problem.
Dieter Maurer wrote:
> Dieter Maurer wrote at 2010-3-16 17:42 +0100:
>> Brian Brinegar wrote at 2010-3-16 10:12 -0400:
>>> Our university relies heavily on a Zope product based on Dieter Maurer's
>>> "Reference" product. Recently, we upgraded from Zope 2.9.6 to Zope
>>> 2.11.x and found some changes in behavior.
>>> In short the Reference product creates a Symlink like pointer in the
>>> Zope hierarchy. Dieter's product can be found on his site at:
>>> First, the security machinery now prevents access to attributes of
>>> References through page template path notation. For example, the
>>> following fails:
>>> * Module zope.tales.expressions, line 217, in __call__
>>> * Module Products.PageTemplates.Expressions, line 133, in _eval
>>> * Module zope.tales.expressions, line 124, in _eval
>>> * Module Products.PageTemplates.Expressions, line 82, in
>>> * Module OFS.Traversable, line 301, in restrictedTraverse
>>> * Module OFS.Traversable, line 232, in unrestrictedTraverse
>>> __traceback_info__: (, 'property_name')
>>> Unauthorized: You are not allowed to access 'property_name' in this context
>> This is a bug/weakness in Zope which affects the "traversal" methods
>> (used for TALES path expressions):
>> When a value is retrieved during traversal via
>> "__bobo_traverse__" which does not have its own
>> security declarations (impossible for a simple datatype),
>> then the traversal insists that it is the same object
>> (verified by object identity) than the object retrieved
>> via "getattr" ("guarded_getattr", to be precise).
>> This drastically restricts the access to simple values
>> via traversal if "__bobo_traverse__" is defined.
>> "Reference" grew a "__bobo_traverse__" method to work
>> around a (apparent) Five bug as delivered with Zope 2.9.
>> Maybe, the "__bobo_traverse__" method is not longer necessary
>> for Zope 2.11. Try to comment it out.
>>> Second, through path notation or URL traversal, References under the
>>> previous version of Zope would default to using methods / objects within
>>> the target before falling back to acquisition. Under Zope 2.11 acquired
>>> methods/objects take priority (only when traversed).
>>> For example, assuming there is an index_html in the root as well as in
>>> the target, and using the following code:
>>> Zope 2.11 yields the path to the acquired index_html:
>>> Zope 2.9.6 yields the path to the index_html in the target:
>>> Again, through python, both yield the second, desired output.
>> This sounds strange -- almost unbelievable.
>> I will look into it within the next few days and report back.
> Thanks to your problem report, I have much better understood
> the problem reported by J Cameron Cooper for Zope 2.9.
> The problem has not been a Five problem. Instead, it was
> caused by a confusion whether the traversal methods
> should be resolved with respect to the reference or its target.
> The primary implementation resolved them with respect to the reference
> and then could not traverse with respect to the target -- J Cameron's problem.
> The "__bobo_traverse__" method partially fixed this again using
> an explicit proxy (which takes into account both reference and target)
> but triggered the security weakness in Zope's traversal for
> simple values.
> A bug in its implementation (a missing "aq_base(...)")
> caused the wrong acquisition context.
> After the improved understanding, I can handle traversal
> methods without a need for "__bobo_traverse__".
> This fixes both of the problems you have observed.
> I will write some tests and then publish "References" as
> "Products.References" on PyPI in the next days.
> Thank you for your problem report!
Web Services Coordinator
Engineering Computer Network
Zope maillist - Zope [at] zope
** No cross posts or HTML encoding! **
(Related lists -