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

[Dan Korostelev]

2009/3/11 Martijn Faassen <faassen at startifact.com>:

> You should write up a short description of what zope.principalregistry
> does. In fact whenever we propose a new package we should describe its
> "mission statement" in just a couple of lines. That'll help us think
> about it better.

I'll add a short README.txt to each package. The
zope.principalregistry is an non-persistent implementation of
IAuthentication that allows us to define principals via zcml (the
"principal" directive and company) or with simple python calls. It's
also quite useful for tests.

>> 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.
>
> Right, that's what I thought. Agreed they should go off into a package
> on its own, probably to eventually die. :) (I have bad memories of
> struggling with this stuff in a sprint in 2003).

Yeah, that's a bit from "TTW development" that is not used much
anymore, I want believe. ;-)

>>>> - 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.
>
> +1
>
> The security declaration I assume can move without introducing
> dependencies on ZCML directives not in zope.security? I think we
> actually moved them in there during the sprint already, if I'm thinking
> about the right directives.

Yeah, it's the "class" directive that was moved to zope.security on that sprint.

>>>> 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.
>
> It really seems odd we're suddenly introducing a new dependency for
> zope.publisher that wasn't there before. You'd think if that dependency
> isn't necessary now it shouldn't be necessary in the futur either. Could
> you delay this refactoring to later in the process at least and bring it
> up again separately when you get to it?

Yep, I think that this refactoring will one of the last, so let's wait
with that indeed.

> Anyway, how theoretical is it that zope.authentication could be used
> with "any request objects"? Does zope.authentication touch the request
> API in your mind at all? Refer to IBrowserRequest?

No. The IAuthentication is meant to work with any request object, even
not zope.publisher's one, like WebOb, or something. The only bits in
current zope.app.security that is tied to zope.publisher is the
implementations if ILoginPassword for zope.publisher's HTTP and FTP
requests. BTW, the only thing that uses ILoginPassword is the "global
principal registry", but the interface is very useful in general.

> A short description of what "zope.authentication" is for would again be
> good, I think.

It's basically the interface-only package that defines
IAuthentication, PrincipalLookupError, IUnauthenticatedPrincipal, and
so on, as well as little helper things, like the "checkPrincipal"
function and the PrincipalSource/PrincipalTerms. It's intented to be
used by any package that doesn't depend on particular authentication
implementation, like zope.securitypolicy and others.

> To avoid overwhelming people with a huge amount of information in one
> mail, I suggest you post to the list for each step. I think this
> overview posting is good, and we should keep it up, but it's also hard
> to judge things individually and a lot to digest, so we should also
> discuss the steps (either before you do it if there are still
> uncertainties, or after you do it).

Okay, I'll mail with a little description of work done for each step.

> I also would like you to write a couple of sentences describing
> zope.authentication, zope.principalregistry and any other new package
> you are thinking of creating. More or less something that could go into
> a README.txt in the introduction, or that could go into the description
> field in setup.py. Something sort so people know what these packages are
> for and can start reasoning about them.

I described them above. But I'll remind about them in any mail that
I'll post about this refactoring process. Also, when I'll be done,
I'll write an general overview of new and changed packages (and after
that we could also add it to 34to35.rst).

-- 
WBR, Dan Korostelev