[Zope] Dieter Mauer's Reference Product

[Dieter Maurer]

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:
>>
>>  http://www.dieter.handshake.de/pyprojects/zope/index.html#bct_sec_5.9
>>
>>First, the security machinery now prevents access to attributes of
>>References through page template path notation. For example, the
>>following fails:
>>
>> tal:content="container/MyReference/property_name"
>>
>>Traceback:
>>  ...
>>  * 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
>>boboAwareZopeTraverse
>>  * 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:
>>
>> tal:content="container/MyReference/index_html/absolute_url_path"
>>
>>Zope 2.11 yields the path to the acquired index_html:
>>
>> /index_html
>>
>>Zope 2.9.6 yields the path to the index_html in the target:
>>
>> /Path/To/Target/index_html
>>
>>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!




--
Dieter