inheriting from SimpleUserFolder's User
hello! i use the SimpleUserFolder product and derive a MyUser class from it's included User class, which in turn inherits from BasicUser. the SimpleUserFolder's User class does neither reimplement getRolesInContext() nor allowed(). i looked at the source of BasicUser (lib/python/AccessControl/User.py) and found out that allowed() does not use the information provided by getRolesInContext(). i found this comment: # Still have not found a match, so check local roles. We do # this manually rather than call getRolesInContext so that # we can incur only the overhead required to find a match. so if i reimplement getRolesInContext() in MyUser, i'll probably also have to reimplement allowed() to reflect the possibly added local roles, right? regards, jürgen herrmann ps: looking at the code of allowed() i doubt that the "manual" checking of local roles will speed this method up a lot: local roles seem to be a seldomly used feature, the improvement in speed would only occur if the object in question was protected by a local role (and not a normal one). is this enough to justify duplicated code with all of it's disadvantages)? _______________________________________________________________________
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:
i use the SimpleUserFolder product and derive a MyUser class from it's included User class, which in turn inherits from BasicUser.
the SimpleUserFolder's User class does neither reimplement getRolesInContext() nor allowed(). i looked at the source of BasicUser (lib/python/AccessControl/User.py) and found out that allowed() does not use the information provided by getRolesInContext(). i found this comment: # Still have not found a match, so check local roles. We do # this manually rather than call getRolesInContext so that # we can incur only the overhead required to find a match.
so if i reimplement getRolesInContext() in MyUser, i'll probably also have to reimplement allowed() to reflect the possibly added local roles, right?
regards, jürgen herrmann
ps: looking at the code of allowed() i doubt that the "manual" checking of local roles will speed this method up a lot: local roles seem to be a seldomly used feature, the improvement in speed would only occur if the object in question was protected by a local role (and not a normal one). is this enough to justify duplicated code with all of it's disadvantages)?
Actually all third-party userfolders I know of reimplement allowed() in terms of calling getRolesInContext(). 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:
Actually all third-party userfolders I know of reimplement allowed() in terms of calling getRolesInContext().
SUF doesn't, it aims to keep Simple ;-) I would like to see this fixed in Zope though, I agree the code that's there probably isn't much fo a performance win... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Jürgen Herrmann wrote at 2005-10-19 15:34 +0200:
i use the SimpleUserFolder product and derive a MyUser class from it's included User class, which in turn inherits from BasicUser.
the SimpleUserFolder's User class does neither reimplement getRolesInContext() nor allowed(). i looked at the source of BasicUser (lib/python/AccessControl/User.py) and found out that allowed() does not use the information provided by getRolesInContext(). i found this comment: # Still have not found a match, so check local roles. We do # this manually rather than call getRolesInContext so that # we can incur only the overhead required to find a match.
so if i reimplement getRolesInContext() in MyUser, i'll probably also have to reimplement allowed() to reflect the possibly added local roles, right?
Yes.
... ps: looking at the code of allowed() i doubt that the "manual" checking of local roles will speed this method up a lot: local roles seem to be a seldomly used feature, the improvement in speed would only occur if the object in question was protected by a local role
Be careful about terminology! Objects are not protected by roles (but by permissions). You gain something if a near local role grants the necessary permission. The "Owner" local role tends to be very near. Thus, you may gain, when usually owners try to execute protected methods.
(and not a normal one). is this enough to justify duplicated code with all of it's disadvantages)?
Nobody prevents you to implement your "allowed" by means of "getRolesInContext". -- Dieter
[ Dieter Maurer wrote:]
Jürgen Herrmann wrote at 2005-10-19 15:34 +0200:
i use the SimpleUserFolder product and derive a MyUser class from it's included User class, which in turn inherits from BasicUser.
the SimpleUserFolder's User class does neither reimplement getRolesInContext() nor allowed(). i looked at the source of BasicUser (lib/python/AccessControl/User.py) and found out that allowed() does not use the information provided by getRolesInContext(). i found this comment: # Still have not found a match, so check local roles. We do # this manually rather than call getRolesInContext so that # we can incur only the overhead required to find a match.
so if i reimplement getRolesInContext() in MyUser, i'll probably also have to reimplement allowed() to reflect the possibly added local roles, right?
Yes.
... ps: looking at the code of allowed() i doubt that the "manual" checking of local roles will speed this method up a lot: local roles seem to be a seldomly used feature, the improvement in speed would only occur if the object in question was protected by a local role
Be careful about terminology! Objects are not protected by roles (but by permissions). k, i'll take care in the future :)
You gain something if a near local role grants the necessary permission. The "Owner" local role tends to be very near.
Thus, you may gain, when usually owners try to execute protected methods. sounds reasonable.
(and not a normal one). is this enough to justify duplicated code with all of it's disadvantages)?
Nobody prevents you to implement your "allowed" by means of "getRolesInContext".
-- Dieter
ok, it just felt a little wrong to reimplement allowed... but if thats the way, fine by me! to dig a little deeper into zope's security machinery, does anybody know where to look at (in the source) f.ex. to find the place where the owner role is assigned to a user? best 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:
[ Dieter Maurer wrote:]
Jürgen Herrmann wrote at 2005-10-19 15:34 +0200:
i use the SimpleUserFolder product and derive a MyUser class from it's included User class, which in turn inherits from BasicUser.
the SimpleUserFolder's User class does neither reimplement getRolesInContext() nor allowed(). i looked at the source of BasicUser (lib/python/AccessControl/User.py) and found out that allowed() does not use the information provided by getRolesInContext(). i found this comment: # Still have not found a match, so check local roles. We do # this manually rather than call getRolesInContext so that # we can incur only the overhead required to find a match.
so if i reimplement getRolesInContext() in MyUser, i'll probably also have to reimplement allowed() to reflect the possibly added local roles, right?
Yes.
... ps: looking at the code of allowed() i doubt that the "manual" checking of local roles will speed this method up a lot: local roles seem to be a seldomly used feature, the improvement in speed would only occur if the object in question was protected by a local role
Be careful about terminology! Objects are not protected by roles (but by permissions).
k, i'll take care in the future :)
You gain something if a near local role grants the necessary permission. The "Owner" local role tends to be very near.
Thus, you may gain, when usually owners try to execute protected methods.
sounds reasonable.
(and not a normal one). is this enough to justify duplicated code with all of it's disadvantages)?
Nobody prevents you to implement your "allowed" by means of "getRolesInContext".
-- Dieter
ok, it just felt a little wrong to reimplement allowed... but if thats the way, fine by me!
to dig a little deeper into zope's security machinery, does anybody know where to look at (in the source) f.ex. to find the place where the owner role is assigned to a user?
That's done by OFS.ObjectManager._setObject. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
participants (4)
-
Chris Withers -
Dieter Maurer -
Florent Guillaume -
Jürgen Herrmann