[Zope-dev] Proposal: refactoring of zope.app.security

[Christian Theune]

On Wed, 2009-03-11 at 15:42 +0100, Martijn Faassen wrote:
> Hey,
> 
> Dan Korostelev wrote:
> > One of most large packages that really wants to be refactored but
> > still wasn't touched is zope.app.security. 
> 
> In fact we did touch it a bit, moving some bits from it into 
> zope.security. And your zope.password work affected its dependencies of 
> course. But I know what you mean. :)
> 
> > It has much in it and it
> > brings many dependencies, including zope.app.form and company. And
> > even some zope.* packages, like zope.securitypolicy still depend on
> > it. So, let's finally refactor it :)
> 
> > Here's a sketch of a refactoring plan I wrote after taking a quick
> > look at the current package:
> > 
> > - Move IAuthentication and other interfaces into new
> > zope.authentication package. Also move there PrincipalSource and the
> > "checkPrincipal" utility function. Also move there the PrincipalTerms
> > class, however that will add dependency on zope.browser (which is
> > really really tiny, as you may know).
> 
> Do you expect bits of zope.app.authentication could also move to 
> zope.authentication or does that look implausible?
> 
> > - Move global principal registry, its IPrincipal/IGroup
> > implementations and its directives into new zope.principalregistry
> > package.
> 
> Why not name it zope.principal?
> 
> > - Move LocalPermission into new zope.localpermission package. I
> > personally didn't ever need local permissions.
> 
> You're talking about locally defined permissions, correct, not about 
> giving someone a permission locally?
> 
> > - Rewrite PermissionsVocabulary and PermissionIdsVocabulary not to
> > depend on zope.app.component and move them into zope.security. It's
> > generally useful there and won't introduce any new dependencies.
> > 
> > - Move zcml definition of zope.Public permission. Maybe move security
> > declaration for the `zope.security.permission.Permission` class as
> > well.
> 
> Move them where?
> 
> > - Leave all browser views, globalmodules.zcml, _protections.zcml,
> > other zope.* permission definitions in zope.app.security as well as
> > backward-compatibility imports.
> > 
> > - Just to note: the "settings" module was recently moved to
> > zope.securitypolicy as there's the right place for it.
> > 
> > Not sure about:
> > 
> > - ILoginPassword and its basic implementations. The interface should
> > probably go into zope.authentication while implementations - into
> > zope.publisher. It will add a dependency on zope.authentication to
> > zope.publisher, but the zope.authentication are expected to be really
> > tiny and already installed for most applications, so I believe that
> > it's okay.
> 
> Why do you think the implementations of ILoginPassword should go into 
> zope.publisher? Why not simply into zope.authentication?
> 
> > - PrincipalLogging - the adapter from
> > zope.security.interfaces.IPrincipal to
> > zope.publisher.interfaces.ILoggingInfo. I'd just move it into
> > zope.publisher, because it's already tied to zope.security.
> 
> Wouldn't zope.publisher then need to depend on zope.principalregistry 
> for the IPrincipal interface?
> 
> > - ILogoutSupported flag interface/adapter. Looks like it's only ever
> > used for enabling/disabling the "logout" button in the UI. I'd
> > deprecate it and leave in zope.app.security.
> > 
> > - _protections.py module. It defines a NoProxy checker for
> > zope.i18nmessageid.Message and adds __name__ and __parent__ attributes
> > to _available_by_default. This module was executed in
> > zope.app.security.__init__ and generally does useful things for most
> > of applications. The problem is that neither zope.i18nmessage, nor
> > zope.location already depend on zope.security. One solution is to move
> > the protections in that packages, placing the code into "try/except
> > ImportError" block to avoid hard dependency.
> 
> That last solution seems reasonable. I think Christian Theune has had 
> some dealings with a strategy like this during our dependency 
> refactoring sprint; Christian?

Sorry, I've stared at the issue for a while but can't remember that I
had (something like) that during the sprint.

-- 
Christian Theune · ct at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20090320/47bb6941/attachment.bin