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