Hi, here is what I have understood in zope3 security policy: On Mon, Feb 21, 2011 at 1:28 PM, Michael Seifert <michael.seif...@gmx.net>wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 04.02.2011 17:04, schrieb Thierry Florac: > > Hi, > > > > > > Le vendredi 4 février 2011, > > Michael Seifert <michael.seif...@gmx.net> a écrit : > > ====================================================================== > >> Hello everyone, > > > >> I recently started a Zope3 project, but I am stuck at the very > >> beginning. Although I have some experience with Zope2, the more > >> flexible approach to developing web applications was giving me a > >> really hard start. Let me point out my situation: > >> I created a container hierarchy which is stored in ZODB. Say I have a > >> set of object types A, B, C, D, whose relationships look like the > >> following (edges represent containment, i.e. A contains B,... where B > >> and D are in subcontainers of A): > > > >> A > >> / \ > >> B D > >> | > >> C > > > >> C has an attribute referencing an object of type D. As this attribute > >> is mandatory on creation, I created a vocabulary, which ascends the > >> hierarchy from the current context until it reaches A and returns all > >> objects of type D. > >> Now the part that doesn't work: > >> While ascending from C to B and from B to A works fine, descending > >> from A to D returns a security proxied object and since these objects > >> cannot be pickled, I cannot store it's reference in the attribute of > >> C. > > > >> 1. Is this the way it's meant to be done? :) What is your opinion of > >> storing B and D objects in subcontainers of A? > > > > That shouldn't be a problem, it's not different when you use a "basic" > > folder-like container which, internally, stores sub-objects in an > > internal b-tree container ; the only difference here is that you own > > two internal containment attributes. > > > > > >> 2. Are there any means to turn the vocabulary into trusted code, so it > >> will not be encapsulated in a proxy (without deactivating the security > >> proxy)? > > > > Perhaps can you use the "removeSecurityProxy" function ? > > > > > >> 3. How do you reference objects like you do with foreign keys in > >> relational databases? I want to do this to prevent objects from being > >> saved multiple times. > > > > If the targetted object is persistent (and so a subclass of > > "Persistent" class), it should be stored only once in the database > > (just try to alter properties of an object and check if the other one > > is also modified or not to check !) > > Another way I commonly use to store references is to store only an > > IIntIds utility reference, which is an integer ; the benefit of this > > is that this value can easilly be indexed. > > > > Regards, > > Thierry > > Thanks Thierry, your answer helped a lot. > > I solved the issue with: > from zope.security.proxy import removeSecurityProxy > def vocab(context): > ... > return SimpleVocabulary.fromValues([removeSecurityProxy(elem) for > elem > in context.values()])) > > > Still, I have some questions regarding the security. > > 1. > When creating the vocabulary with > return SimpleVocabulary.fromValues([elem.someFunc() for elem in > context.values()])) > I noticed that elem in context.values() are not proxied yet, so the > actual wrapping must take place before the values are passed to the ZMI. > How does calling the removeSecurityProxy function prevent the objects > from being wrapped, since the wrapping takes place AFTER the function call? > (I had a look at the sources, but the implementation resides in > zope.security._proxy which is a binary .so file) > > > The removeSecurityProxy does not prevent the object from being proxied: it allows the storage of the object in an attribute without its proxy. The original object will always be proxied. > 2. > The vocabularies are registered as utilities in the .zcml file(s). > Since access to objects from these vocabularies is not checked by a > security proxy: Is it therefore possible that any user can access the > vocabulary data? > If so, is there a way to restrict access to the utility vocabularies? > > You can use the utility permission attribute. > Regards, > Michael > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk1iWlAACgkQnzX+Jf4GTUxO2gCeIoKh8l+6QaGsDo07WKUT2Y94 > BDQAn16rtkPVIIPo5N8a2K7A/SsOdoQU > =dHUQ > -----END PGP SIGNATURE----- > _______________________________________________ > Zope3-users mailing list > Zope3-users@zope.org > https://mail.zope.org/mailman/listinfo/zope3-users > Regards, Simon
_______________________________________________ Zope3-users mailing list Zope3-users@zope.org https://mail.zope.org/mailman/listinfo/zope3-users