"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."
I think this new security checks could be a problem in some cases. They are Ok when using restricted code, but from trusted code I'm not sure that force to use restrictedTraverse could be considered a goal.
For instance, imagin an application with employees of one department managing dossiers with economic data inside. Employees of accounting department shouldn't have access to these dossiers objects, but they need to obtain some reports with a sum of all dossiers economic data. So, accounting department users shouldn't have access to dossiers objects, but from reports trusted code these dossiers need to accessed.
I think a possible solution could be an additional optional parameter of .getobject used from trusted code when unrestrictedTraverse want to be used. What do you think ?
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce