implicit vs. explicit ownership?
in AccessControl.Owned.Owned: def manage_changeOwnershipType(explicit=1, RESPONSE=None, REQUEST=None): """Change the type (implicit or explicit) of ownership. """ can somebody please explain what's the difference between explicit and implicit here, or provide a rtfm hint? regards, juergen herrmann _______________________________________________________________________
XLhost.de - eXperts in Linux hosting <<
Jürgen Herrmann Bruderwöhrdstraße 15b, DE-93051 Regensburg Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)721 151 463027 WEB: http://www.XLhost.de
Jürgen Herrmann wrote:
in AccessControl.Owned.Owned:
def manage_changeOwnershipType(explicit=1, RESPONSE=None, REQUEST=None): """Change the type (implicit or explicit) of ownership. """
can somebody please explain what's the difference between explicit and implicit here, or provide a rtfm hint?
Note that this is *executable* ownership, about which few people care (except those that develop code-like objects). Read http://www.zope.org/Members/jim/ZopeSecurity/ServerSideTrojan for background. Here the "implicit" or "explicit" executable ownership is just the fact that the _owner is acquired from the parent or explicitely set on the object. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
[ Florent Guillaume wrote:]
Jürgen Herrmann wrote:
in AccessControl.Owned.Owned:
def manage_changeOwnershipType(explicit=1, RESPONSE=None, REQUEST=None): """Change the type (implicit or explicit) of ownership. """
can somebody please explain what's the difference between explicit and implicit here, or provide a rtfm hint?
Note that this is *executable* ownership, about which few people care (except those that develop code-like objects). Read http://www.zope.org/Members/jim/ZopeSecurity/ServerSideTrojan for background.
Here the "implicit" or "explicit" executable ownership is just the fact that the _owner is acquired from the parent or explicitely set on the object.
thanks for your answer... hmm, i'm a bit confused now. do you say that changeOwnershipType() only has to do with "executeable ownership"? especially i have to know which methods of the IOwned interface are essential and have to be reimplemented properly on my objects. ...but the fog is clearing up a little bit now, i thought that the "owner" role would be completely dynamically assigned to a user by getRolesInContext, now i see that this is done at object creation time and more than one user can have the local role "owner" on an object. for my use cases i'd prefer to let getRolesInContext() add the "owner" role to it's return list if the (runtime and proprietary) owner check tells it to. any contraindications (besides performance, possibly)? regards, juergen herrmann _______________________________________________________________________
XLhost.de - eXperts in Linux hosting <<
Jürgen Herrmann Bruderwöhrdstraße 15b, DE-93051 Regensburg Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)721 151 463027 WEB: http://www.XLhost.de
Jürgen Herrmann wrote:
hmm, i'm a bit confused now. do you say that changeOwnershipType() only has to do with "executeable ownership"?
Yep, I think so...
especially i have to know which methods of the IOwned interface are essential and have to be reimplemented properly on my objects.
Why do you think you need to implement IOwned?
...but the fog is clearing up a little bit now, i thought that the "owner" role would be completely dynamically assigned to a user by getRolesInContext, now i see that this is done at object creation time and more than one user can have the local role "owner" on an object.
The Owner role is something of a dead chicken. Don't rely on it and ignore it as best you can unless you're really sure what you're doing...
for my use cases i'd prefer to let getRolesInContext() add the "owner" role to it's return list if the (runtime and proprietary) owner check tells it to. any contraindications (besides performance, possibly)?
Well, confusion. I'd just get a new role name and use that for whatever you want to do... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Withers wrote:
Jürgen Herrmann wrote:
hmm, i'm a bit confused now. do you say that changeOwnershipType() only has to do with "executeable ownership"?
Yep, I think so...
especially i have to know which methods of the IOwned interface are essential and have to be reimplemented properly on my objects.
Why do you think you need to implement IOwned?
Unless Juergen's object is "code-like", IOwned is a distraction; ownable objects exist only to prevent trojaning (as Chris correctly pointed out earlier).
...but the fog is clearing up a little bit now, i thought that the "owner" role would be completely dynamically assigned to a user by getRolesInContext, now i see that this is done at object creation time and more than one user can have the local role "owner" on an object.
The Owner role is something of a dead chicken. Don't rely on it and ignore it as best you can unless you're really sure what you're doing...
I don't know why you would say that. The "Owner" local role (as opposed to executable ownership) is widely used to allow creators of content to edit it in places where they would otherwise be unable to do so.
for my use cases i'd prefer to let getRolesInContext() add the "owner" role to it's return list if the (runtime and proprietary) owner check tells it to. any contraindications (besides performance, possibly)?
It *is* possible to hijack the role computation here; getting it right is tricky, however, and when it is wrong, your error messages are going to be inscrutable. The "right" place to do this might be in a custom user folder, rather than in content. PAS, for instance, has the concept of making the role computation for the *user* pluggable. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDWQ/D+gerLs4ltQ4RAqGEAKC90sJHo7JjtfSGowvBpLbGxpvt4wCdGCm5 Yp0mtxCE1M2hL6SIgYRF7wo= =l8J6 -----END PGP SIGNATURE-----
Tres Seaver wrote:
The Owner role is something of a dead chicken. Don't rely on it and ignore it as best you can unless you're really sure what you're doing...
I don't know why you would say that. The "Owner" local role (as opposed to executable ownership) is widely used to allow creators of content to edit it in places where they would otherwise be unable to do so.
Indeed, but people alwys get it mixed up with executable ownership, or some other kind of voodoo, and so are scared to treat it just like any other role, which is wha tthey should do ;-)
It *is* possible to hijack the role computation here; getting it right is tricky, however, and when it is wrong, your error messages are going to be inscrutable. The "right" place to do this might be in a custom user folder, rather than in content. PAS, for instance, has the concept of making the role computation for the *user* pluggable.
My gut feeling is he doesn't really want to do any of that though... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (4)
-
Chris Withers -
Florent Guillaume -
Jürgen Herrmann -
Tres Seaver