Re: Re: [Zope-dev] CatalogBrains since Zope2.7.1b1
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 CatalogBrains.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. Sorry for my english thanks for your answers
Eric Brun wrote at 2004-6-16 11:16 +0200:
I have a problem with 'getObject' method of CatalogBrains class on Zope271b>1 : it's return None. But with a Zope2.7.0 my object is correctly find and returned. The permissions are right.
is there any bug here ?
They return "None" when the object no longer exists.
Check the path ("getPath" method) and verify whether the object exists.
-- Dieter
Eric Brun Ingénieur de développement eric.brun@pentila.com Pentila Bâtiment Euclide 73370 Le Bourget du Lac Savoie Technolac http://www.pentila.com
--On Donnerstag, 17. Juni 2004 11:32 Uhr +0200 Eric Brun <eric.brun@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. Thanks for your cooperation, Andreas
On Fri, 18 Jun 2004 07:13:15 +0200 Andreas Jung <lists@zopyx.com> wrote:
--On Donnerstag, 17. Juni 2004 11:32 Uhr +0200 Eric Brun <eric.brun@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
Casey Duncan wrote at 2004-6-18 09:58 -0400:
... 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.
I think, you should only require access rights to the object itself and not to all folders from the root to the object. It is not uncommon that upper levels are more restricted than subhierarchies. This is what Zope's URL traversal allows: Only the object identified by URL traversal is accessed checked. That ZCatalog identifies objects by physical path is an implementation artifact. It should not make it impossible to access an object via the catalog that otherwise can be accessed without problem.
... For hysterical raisins, REQUEST.traverse() does not behave this way. It instead checks only the final object traversed. That's a good behaviour...
-- Dieter
On Thu, 24 Jun 2004 19:04:55 +0200 Dieter Maurer <dieter@handshake.de> wrote:
Casey Duncan wrote at 2004-6-18 09:58 -0400:
... 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.
I think, you should only require access rights to the object itself and not to all folders from the root to the object.
It is not uncommon that upper levels are more restricted than subhierarchies. This is what Zope's URL traversal allows: Only the object identified by URL traversal is accessed checked.
That ZCatalog identifies objects by physical path is an implementation artifact. It should not make it impossible to access an object via the catalog that otherwise can be accessed without problem.
... For hysterical raisins, REQUEST.traverse() does not behave this way. It instead checks only the final object traversed. That's a good behaviour...
Except when it isn't ;^) OTOH it is closer to the behavior of getObject in 2.7.0. Ironically it used to use restrictedTraverse long ago... -Casey
Casey Duncan wrote at 2004-6-25 09:36 -0400:
On Thu, 24 Jun 2004 19:04:55 +0200 Dieter Maurer <dieter@handshake.de> wrote: ...
I think, you should only require access rights to the object itself and not to all folders from the root to the object. ... That ZCatalog identifies objects by physical path is an implementation artifact. It should not make it impossible to access an object via the catalog that otherwise can be accessed without problem.
... For hysterical raisins, REQUEST.traverse() does not behave this way. It instead checks only the final object traversed. That's a good behaviour...
Except when it isn't ;^) OTOH it is closer to the behavior of getObject in 2.7.0. Ironically it used to use restrictedTraverse long ago...
Have you gotten the main argument? That ZCatalog identifies objects by physical path is an implementation artifact. It should not make it impossible to access an object via the catalog that otherwise can be accessed without problems. When you implement "getObject" via "restrictedTraverse", then you let "getObject()" fail for some objects that *are* accessible by the current user (because this access need not to use the complete path from the root). Do not do that! -- Dieter
On Fri, 25 Jun 2004 20:26:30 +0200 Dieter Maurer <dieter@handshake.de> wrote:
Casey Duncan wrote at 2004-6-25 09:36 -0400:
On Thu, 24 Jun 2004 19:04:55 +0200 Dieter Maurer <dieter@handshake.de> wrote: ...
I think, you should only require access rights to the object itself and not to all folders from the root to the object. ... That ZCatalog identifies objects by physical path is an implementation> artifact. It should not make it impossible to access an> object via the catalog that otherwise can be accessed without problem.
... For hysterical raisins, REQUEST.traverse() does not behave this way.> >It instead checks only the final object traversed. That's a good behaviour...
Except when it isn't ;^) OTOH it is closer to the behavior of getObject in 2.7.0. Ironically it used to use restrictedTraverse long ago...
Have you gotten the main argument?
Yes, I intend to change it to use unrestrictedTraverse and then validate the returned object. So there... 8^P -Casey
participants (4)
-
Andreas Jung -
Casey Duncan -
Dieter Maurer -
Eric Brun