Alec Mitchell wrote at 2006-4-16 12:28 -0700:
>It seems that the way OFS.Traversable.restrictedTraverse() handles
>security checking on objects with __bobo_traverse__ methods is
>considerably different from the way it normally checks security. The
>result is that traversal cannot obtain attributes using acquisition
>from objects that are marked <five:traversable>. In the normal case,
>security is checked using guarded_getattr, which gets an attribute and
>checks the permissions on the retrieved object in its original
>context. For __bobo_traverse__methods which return simple properties
>(say strings), it is impossible to determine the container from which
>the returned attribute originates, so unless the attribute was not
>acquired, an Unauthorized error will always be raised.
>However, IMHO fixing this makes sense for Zope itself,
>provided there aren't any undesirable consequences. I propose that if
>the validation of a __bobo_traverse result raises Unauthorized, that
>we make one last check to see if the result o 'guarded_getattr(obj,
>name)' is identical to the result of the __bobo_traverse__ call and
>allow it if that's the case. Here is my proposed patch against Zope
In our local Zope version, I implemented a solution that is
(in my opinion) superior:
Define an exception "UseTraversalDefault" that can be
used by "__bobo_traverse__" to tell the traversal process
(either URL traversal in the publisher or restricted/unrestricted/CMF
traversal) to use the default lookup.
One big advantage is that e.g.
"Archetypes.BaseObject.BaseObject.__bobo_traverse__" no longer
need this horrible dance to decide whether it should or must
not create a "NullResource".
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -