Common permissions (final bits of zope.app.security refactoring)
Hey, people! The refactoring of zope.app.security is now almost done. There's still some polishing work to do and two little issues to resolve. One of them is the zope's "common permissions". Most of zope.* and zope.app.* (and other) packages define some security protections for their classes and views using common permission names defined in zope.app.security. We decided to move those permission definitions to a separate and excludable/overridable zcml file to zope.security, so packages that use them would't need to install anything additional. But we want only generic and useful permissions to be a part of "common set", so we need to select ones from zope.app.security. Currently, zope.app.security defines these permissions (not counting zope.Public, that already migrated to zope.security): - zope.View - zope.Security - zope.ManageContent - zope.ManageBindings - zope.ManageCode - zope.ManageServices - zope.ManageSite - zope.ManagePrincipals - zope.ManageApplication Permissions, that needs to be in a common set (IMHO), mostly because it's used by current zope.* packages: - zope.View - zope.ManageContent - zope.Security - zope.ManageServices - zope.ManageSite To be honest, I don't quite get the difference between zope.ManageSite and zope.ManageServices. Can someone clear this point for me? May be they should be merged somehow. Permissions that can stay in zope.app.security, and reasons: - zope.ManageBindings - What's that? I can't find any usage of it. - zope.ManagePrincipals - That looks like it was intended for something like zope.app.authentication, but zope.ManageServices is used there instead. - zope.ManageCode - I guess it's intended for TTW development that's not used/developed much and even discouraged now-a-days? If so, I believe that it can stay in zope.app.security. - zope.ManageApplication - Looks like it's intended for and used mostly in "zope.app.applicationcontrol" which has more to do with "zope3, the application server", than the "zope.framework". -- WBR, Dan Korostelev
Hey Dan, Thanks very much for this analysis and summary! My comments below. Dan Korostelev wrote:
To be honest, I don't quite get the difference between zope.ManageSite and zope.ManageServices. Can someone clear this point for me? May be they should be merged somehow.
I'm afraid I don't know either. If we want to merge them we'd need to do some analysis of places where they are used. For now, move them both over.
Permissions that can stay in zope.app.security, and reasons:
- zope.ManageBindings - What's that? I can't find any usage of it.
Then it should stay where it is. :)
- zope.ManagePrincipals - That looks like it was intended for something like zope.app.authentication, but zope.ManageServices is used there instead.
A clear case of leaving it behind to die too.
- zope.ManageCode - I guess it's intended for TTW development that's not used/developed much and even discouraged now-a-days? If so, I believe that it can stay in zope.app.security.
Yes, TTW in Zope 3 is currently dead, let's not worry about supporting it in the Zope Framework (we don't even have a ZMI there). Let it stay there.
- zope.ManageApplication - Looks like it's intended for and used mostly in "zope.app.applicationcontrol" which has more to do with "zope3, the application server", than the "zope.framework".
I will note that zope.app.applicationcontrol contains code that looks reusable, even though it is indeed a bit more "application-like". Grok's grokui.admin uses it so it'd be interesting to extract this code into a library we can use. I also just discovered zope.app.applicationcontrol doesn't seem to declare its dependencies right - it appears to depend on zope.app.appsetup for instance while it doesn't actually declare it. Anyway, we can always move zope.ManageApplication into zope.app.applicationcontrol when we want to, so leave it in zope.app.security for now. Regards, Martijn
2009/3/12 Martijn Faassen <faassen@startifact.com>:
Thanks very much for this analysis and summary! My comments below. [...snip...]
Okay, the move is now done.
Anyway, we can always move zope.ManageApplication into zope.app.applicationcontrol when we want to, so leave it in zope.app.security for now.
+1 -- WBR, Dan Korostelev
Hi, On Thu, 2009-03-12 at 15:32 +0100, Martijn Faassen wrote:
Hey Dan,
Thanks very much for this analysis and summary! My comments below.
Dan Korostelev wrote:
To be honest, I don't quite get the difference between zope.ManageSite and zope.ManageServices. Can someone clear this point for me? May be they should be merged somehow.
I'm afraid I don't know either. If we want to merge them we'd need to do some analysis of places where they are used. For now, move them both over.
Services used to be a concept of the Component Architecture. This might be a remnant permission. Is it actually used somewhere? If so, I guess that it's fine to fold that permission into zope.ManageSite.
I will note that zope.app.applicationcontrol contains code that looks reusable, even though it is indeed a bit more "application-like". Grok's grokui.admin uses it so it'd be interesting to extract this code into a library we can use.
I also just discovered zope.app.applicationcontrol doesn't seem to declare its dependencies right - it appears to depend on zope.app.appsetup for instance while it doesn't actually declare it.
Anyway, we can always move zope.ManageApplication into zope.app.applicationcontrol when we want to, so leave it in zope.app.security for now.
ManageSite and ManageApplication differ in the sense that ManageSite very likely only applies locally (at a site) whereas the application is a global thing (the server that runs everything) that needs management (like shutting down the server) independent of giving someone the right to administer a site (or even the top-level site). Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
participants (3)
-
Christian Theune -
Dan Korostelev -
Martijn Faassen