Does it work to just set __parent__ to the container? Or does the zopesecuritypolicy require more accurate context?


Martijn Faassen wrote:
Hi there,

In working with Zope 3 to build an application, I repeatedly run into the following situation:

* user gets a local role on a container

* object is created

* after object creation but before the object is added,
  various things are done to the object.

* authorization error: user cannot access various attributes.

Now, the user would've had access to this after the object is added to the container, as then the role would've been acquired. In this latest the container the object is added to is actually *dependent* on the state of the object, though. Besides, sometimes one wants to mess with object attributes *before* adding it and thus getting it, say, cataloged.

Now in Zope 2 this is:

* normal as everything needs to be acquisition wrapped

* not a problem as filesystem code is trusted

In Zope 3, filesystem code is not trusted, and now this actually bites me more than it ever did in Zope 2.

This is frustrating. I can hack around it by sprinkling removeSecuritProxy throughout the codebase, but that's certainly not pretty. Zope 3 is usually very nice about context not being dependent on location (I see now why getSite() is very nice), but the security case is an exception.

I don't have a concrete proposal about what should be done. I guess the paradox is that on the one hand I *want* acquisition of role information from the container (as the security model this application has is quite involved), and on the other hand I keep getting bitten by it.

My problem is only with zopesecuritypolicy. At first I thought about implementing my own security policy for this application, but this got quickly very hairy, so I decided to stick to Zope's.

I guess this also ties in to Steve Alexander's ongoing campaign against location (as opposed to site) dependence in Zope 3. Maybe he has a better idea how to resolve this...



Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   [EMAIL PROTECTED]

Zope3-dev mailing list

Reply via email to