Martijn Faassen wrote:
General problem description:
For a ZClass instance/external methods that is only viewable by users with a particular role, the view operation fails if that role is only added to a user in a place deeper in the folder tree than the folder where the External Method/ZClass instance was defined. This occurs when the 'view' is occuring in the acquisition context of the folder.
It succeeds if the role is added to the user in a folder higher in the tree, at or above the folder where the external method or ZClass instance is defined.
This sounds 100% correct. When checking security, acquisition context is ignored. What matters is *containment* (which is also accessed through the acquisition machinery, but in a special way: aq_inner). A user can only access objects that are defined in a container where the user is granted access. You probably don't really want to change it to use context instead. It would open a mile-wide security hole.
The view operation fails with a reauthentication request in Zope 2.1.6 (so authentication exception raised presumably).
In Zope 2.2.2 the failure is a NameError for External Methods, and reauthentication for ZClass instances.
Am I missing something terribly obvious, or is this a rather huge bug that's been unnoticed for a long time? I assume it *must* be a bug as DTML methods behave in a different way. I also want it to be a bug, as I don't like this behavior. It makes it very hard to delegate responsibility.
The difference is a result of the change in the way security is handled. It now gets a NameError because the name lookups skip over entries to which you're disallowed access. That logic can be very puzzling, but you might try the ZDebug product which helps you make sense of it. Shane