zope.localpermission and the "zope app permissions"
Hi people! As a part of zope.app.security refactoring process, I extracted local (persistent) permissions to new "zope.localpermission". And I faced one problem and I'm not sure about its resolution. Originally, I wanted to only move the "zope.Public" permission declaration into zope.security, because that permission name is special and always available. As for other permissions (zope.View/zope.Security/zope.ManageContent, etc.), I wanted to just leave them in zope.app.security as is. But security declarations for the "LocalPermission" class in zope.localpermission needs the "zope.Security" permission. Also, some of those permissions are used much in other zope.* packages for zcml security declarations. So, I wonder what should we do with this. One variant that seems nice to me is to create a package, called like "zope.genericpermissions" and place there the zcml file with permission definitions. I believe that not all permissions are used (for example, what's zope.ManageBindings?), so we could select only truly generic and needed permissions and leave the rest in zope.app.security. Opinions? Oh, and on the topic, one more time: can we have a steering group decision on the package requirements for zcml statements? Are we doing extras for them or simply skipping them? -- WBR, Dan Korostelev
Hey, Dan Korostelev wrote:
As a part of zope.app.security refactoring process, I extracted local (persistent) permissions to new "zope.localpermission". And I faced one problem and I'm not sure about its resolution.
Originally, I wanted to only move the "zope.Public" permission declaration into zope.security, because that permission name is special and always available. As for other permissions (zope.View/zope.Security/zope.ManageContent, etc.), I wanted to just leave them in zope.app.security as is.
But security declarations for the "LocalPermission" class in zope.localpermission needs the "zope.Security" permission. Also, some of those permissions are used much in other zope.* packages for zcml security declarations.
So, I wonder what should we do with this.
If it doesn't introduce new dependencies, I think a few more definitions of permissions in zope.security won't hurt (only those commonly used). I'd like that better than introducing a new package. Do you think this will be tolerable to you? We should indeed only move those widely used. The problem we have is that some content objects (i.e. not only the ZMI) declare that some of their methods need permissions. In order to support those we do need to have the definitions in a central place, and I think zope.security would be as good as any if we can do it without introducing more dependencies. Just put them in a separate submodule and we should be okay.
Oh, and on the topic, one more time: can we have a steering group decision on the package requirements for zcml statements? Are we doing extras for them or simply skipping them?
Sorry, I wasn't clear that there was an open question and I'm afraid I don't understand this one. :) Could you point me to the appropriate thread that was left in the middle, or could you start a new thread with a description of the open question? Regards, Martijn
2009/3/11 Martijn Faassen <faassen@startifact.com>:
Dan Korostelev wrote:
Originally, I wanted to only move the "zope.Public" permission declaration into zope.security, because that permission name is special and always available. As for other permissions (zope.View/zope.Security/zope.ManageContent, etc.), I wanted to just leave them in zope.app.security as is.
But security declarations for the "LocalPermission" class in zope.localpermission needs the "zope.Security" permission. Also, some of those permissions are used much in other zope.* packages for zcml security declarations.
So, I wonder what should we do with this.
If it doesn't introduce new dependencies, I think a few more definitions of permissions in zope.security won't hurt (only those commonly used). I'd like that better than introducing a new package. Do you think this will be tolerable to you?
I also thought about this, but I decided that people will be against that, because zope.security is intended to be really generic and only permission it defines is the special "zope.Public" (there even was discussions about renaming it to plain "public"). However, it's fine with me, as long as we define them in a separate zcml file that can be excluded and/or redefined for some special case.
We should indeed only move those widely used.
That will require some research. When I'll be doing that, I'll post my opinion on what permissions should go to "standard" ones and what to deprecate and will call for comments and more information.
The problem we have is that some content objects (i.e. not only the ZMI) declare that some of their methods need permissions. In order to support those we do need to have the definitions in a central place, and I think zope.security would be as good as any if we can do it without introducing more dependencies. Just put them in a separate submodule and we should be okay.
Yup, fine then. However, I think that there's no need for a submodule when we can do that in simple separate zcml file. Or I miss something? -- WBR, Dan Korostelev
Dan Korostelev wrote:
2009/3/11 Martijn Faassen <faassen@startifact.com>: [snip]
If it doesn't introduce new dependencies, I think a few more definitions of permissions in zope.security won't hurt (only those commonly used). I'd like that better than introducing a new package. Do you think this will be tolerable to you?
I also thought about this, but I decided that people will be against that, because zope.security is intended to be really generic and only permission it defines is the special "zope.Public" (there even was discussions about renaming it to plain "public"). However, it's fine with me, as long as we define them in a separate zcml file that can be excluded and/or redefined for some special case.
I think in the interest of avoiding an extra package, we should move it into zope.security right now. The main ZCML file should load an extra ZCML file taht can be excluded. The extra load on zope.security seems to be really light and it'll be easy to factor it out later should it be necessary.
We should indeed only move those widely used.
That will require some research. When I'll be doing that, I'll post my opinion on what permissions should go to "standard" ones and what to deprecate and will call for comments and more information.
All right, thanks.
Yup, fine then. However, I think that there's no need for a submodule when we can do that in simple separate zcml file. Or I miss something?
Ah, sorry, it's purely ZCML. No, I missed something, go ahead. Regards, Martijn
participants (2)
-
Dan Korostelev -
Martijn Faassen