Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: Users

Dieter Mauer's Reference Product

 

 

Zope users RSS feed   Index | Next | Previous | View Threaded


brinegar at ecn

Mar 16, 2010, 7:12 AM

Post #1 of 5 (1174 views)
Permalink
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
_______________________________________________
Zope maillist - Zope [at] zope
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 )


dieter at handshake

Mar 16, 2010, 9:42 AM

Post #2 of 5 (1156 views)
Permalink
Re: Dieter Mauer's Reference Product [In reply to]

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
_______________________________________________
Zope maillist - Zope [at] zope
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 )


akm at theinternet

Mar 16, 2010, 9:49 AM

Post #3 of 5 (1170 views)
Permalink
Re: Dieter Mauer's Reference Product [In reply to]

+-------[ 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 [at] theinternet
_______________________________________________
Zope maillist - Zope [at] zope
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 )


dieter at handshake

Mar 16, 2010, 1:00 PM

Post #4 of 5 (1159 views)
Permalink
Re: Dieter Mauer's Reference Product [In reply to]

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
_______________________________________________
Zope maillist - Zope [at] zope
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 )


brinegar at ecn

Mar 16, 2010, 1:07 PM

Post #5 of 5 (1154 views)
Permalink
Re: Dieter Mauer's Reference Product [In reply to]

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 [at] zope
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 )

Zope users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.