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 _______________________________________________ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )