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

[Dan Korostelev]

2009/3/11 Martijn Faassen <faassen at startifact.com>:
>>
>> - 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?

No, I don't think that anything from zope.app.authentication should go
to zope.authentication. It probably should go to something like
zope.pluggableauthentication. I expect zope.authentication to be tiny
package that only define interfaces and very basic utilities.

>> - Move global principal registry, its IPrincipal/IGroup
>> implementations and its directives into new zope.principalregistry
>> package.
>
> Why not name it zope.principal?

It sounds confusing to me. Also, the global principal registry is just
an (one of) implementation of IAuthentication, while zope.principal
sounds like something from the "core" of principals.

>> - 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?

I'm talking about local persistent permissions that can be added to
ZODB and registered per site. It's zope.securitypolicy that gives
local permissions, so, LocalPermission has nothing to do with local
grants.

>> - 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?

Oh, that's a typo. Move them to zope.security.

>> 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?

Because that implementations are zope.publisher specific, while
zope.authentication as I see it could be used with any request objects
and that way it could not depend on zope.publisher.

>> - 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?

No. IPrincipal is defined in zope.security.

> In general, I'd be careful to execute each of these as a separate step,
> and not try to do them all at once. It's quite possible that while
> you're moving stuff around (including tests) that you'll suddenly think
> of a better place, so better treat this on a case by case basis when you
> actually start.

Yeah, I was already planning to that step by step.

-- 
WBR, Dan Korostelev