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.
How is the new object being security proxied? Is it being created
by a security proxied factory? Generally, new objects aren't
proxied in the first place.
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,
It is trusted, but not as far as it was in Zope 2. It can import
anything it wants and this has access to lots of unproxied objects,
uncluding utilities. It does get proxied data passed to it from
untrusted code.
> 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.
No, but, done in moderation and with care, it is at least explicit.
> 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'm still puzzled why new objects are being proxied in the first place.
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.
FWIW, we will (soon I hope) be releasing a new security policy that doesn't
use acquisition nearly as much. In partiocular, for objects that that can
have security assertions, it doesn't acquire security assertions. I'm not
sure that will help you because you still have to actually make the assertions
on the new objects and, if the object is security proxied, then the you won't
have permission to make the assertions. :)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
[email protected]
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
