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...
Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
