[Zope] Dieter Mauer's Reference Product

[Brian Brinegar]

Dieter,

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.

Thank you,

Brian


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:
>>>
>>>  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
> 

-- 
Brian Brinegar
Web Services Coordinator
Engineering Computer Network