Dieter Mauer's Reference Product
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 Interestingly, the same access via dot notation works: tal:content="python:container.MyReference.property_name There were substantial changes to Traversable.py between versions which seem to cause the problem. Any suggestion on how to fix this would be greatly appreciated. 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. I realize this is an obscure product, and the changes seem to have to do with the Five implementation. At this point we are looking for options to restore the desired functionality which does not require perpetually running Zope 2.9.x One option may be to change everything to dot notation, however I would at least like to understand why this change occurred. Thanks for reading, -- Brian Brinegar Web Services Coordinator Engineering Computer Network
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. -- Dieter
+-------[ Dieter Maurer ]---------------------- | Brian Brinegar wrote at 2010-3-16 10:12 -0400: | > ... | >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. | 2.10 is when TALES/TAL/ZPT were back-ported from Z3 into Z2, so not really unbelievable d8) Otherwise working things break crossing the 2.9/2.10 barrier. I imagine the behaviour will be present from 2.10 onwards. -- Andrew Milton akm@theinternet.com.au
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
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
participants (3)
-
Andrew Milton -
Brian Brinegar -
Dieter Maurer