[Zope-dev] Re: CatalogBrains since Zope2.7.1b1

[Casey Duncan]

On Fri, 18 Jun 2004 07:13:15 +0200
Andreas Jung <lists at zopyx.com> wrote:

> 
> 
> --On Donnerstag, 17. Juni 2004 11:32 Uhr +0200 Eric Brun 
> <eric.brun at pentila.com> wrote:
> 
> >
> >
> > My object really exist and I check the getPath path : it's a correct
> > path.
> >
> > When I use CatalogBrains.py of Zope2.7.0 on a Zope2.7.1b1,
> > my object is correctly returned. The changes in the version of
> > CatalogBrain= s.py in Zope2.7.1b1 can't find my existing object with
> > a good path. I think=  there is a problem here. =
> >
> >
> > I just alert a potential bug for the zope-dev community.
> >
> 
> I would really appreciate if you could provide a reproducable
> testcase. Otherwise
> it is unlikely that this will be fixed (for 2.7.1 final). Guessing is
> one thing, providing
> reasonable evidence is another thing. As Zope 2.7 release manager I am
> 
> interested to
> have such bugs fixed *but*  I don't have time to figure out for *you*
> what might be the
> problem on *your* system.

Security was tightened for getObject recently as part of a general
refactor of that code. I am happy to consider whether the security is
too tight, in which case it could be backed off a bit.

Previously getObject performed no security checks and returned objects
for catalog results regardless of security permissions (it used
unrestrictedTraverse). I switched it to use restrictedTraverse which
checks security all the way down on all of the containing folders and on
the final object itself. This is how path expressions work, for example.

For hysterical raisins, REQUEST.traverse() does not behave this way. It
instead checks only the final object traversed. It might be reasonable
for ZCatalog to act this way, but I would need to be convinced ;^). I
consider the difference in these traversal behaviors to be a wart, but
one that is not easily fixed given application reliance on both
behaviors.

Another suspect behavior we might reconsider is the implicit contract
that getObject should not raise exceptions. Right now if the object
cannot be returned for any reason (such as it cannot be accessed due to
parent security settings) getObject returns None. It would probably be
better for it to raise the appropriate exception, but I think this would
break BW compatibility, *sigh*.

-Casey