New package: zope.authentication AND the problem.
Hey, community. As a part of zope.app.security refactoring process, a new package has been created - "zope.authentication". It basically contains IAuthentication and other auth-related interfaces, as well as PrincipalSource. So it's intended to define a basic concepts and contracts of principal authentication for the zope framework to be implemented by other packages. There are three implementations that I know of currently: the "global principal registry" from zope.app.security (it will be moved into new package, called "zope.principalregistry"), the zope.app.authentication and z3c.authenticator. It's quite request type independent so it can be used with non-zope.publisher requests, like WebOb or something, but here the problem appears: The zope.app.security defines the ILoginPassword (getLogin,getPassword,needLogin) adapters for zope.publisher's HTTP and FTP requests. I wonder where should they go, because the "zope.authentication" package doesn't want to depend on zope.publisher, as (like i said before) it is intended to be tiny and independent on any request implemenation. I'd move those adapters into zope.publisher itself, but this will require adding the "zope.authentication" dependency for zope.publisher, which I think is okay, because zope.authentication is very small and will probably be used together with zope.publisher anyway. Another solution which I like much less is to move those adapters to "zope.authentication" and define an extra dependency (sigh) on zope.publisher, but then the package won't be so nice, clean and generic as it could be. :-) Opinions? -- WBR, Dan Korostelev
Hey, Thanks for bringing this up and describing the problem so clearly. I'm going to answer with a bunch of questions in the hope it will lead us into the right direction for this problem. Dan Korostelev wrote: [snip]
Another solution which I like much less is to move those adapters to "zope.authentication" and define an extra dependency (sigh) on zope.publisher, but then the package won't be so nice, clean and generic as it could be. :-)
One question I have is how theoretical this genericity is. Do we have concrete use cases for using this zope.authentication outside of a Zope context? What would that look like? Do we really expect people to show up and say: "hey, I'll use this for my project that doesn't use zope.publisher at all!". We can also ask it in another way: if zope.authentication were not to depend on zope.publisher, would zope.principalregistry not depend on zope.publisher either? What about zope.app.authentication and z3c.authenticator? (imagining any of their ZMI away for now). Would *those* packages then be useful independently from zope.publisher? I still feel bad about zope.publisher needing to know about authentication (in the dependency sense) where it doesn't today. Is that really true: does it today really not do anything with authentication? Regards, Martijn
2009/3/12 Martijn Faassen <faassen@startifact.com>:
Dan Korostelev wrote: [snip]
Another solution which I like much less is to move those adapters to "zope.authentication" and define an extra dependency (sigh) on zope.publisher, but then the package won't be so nice, clean and generic as it could be. :-)
One question I have is how theoretical this genericity is. Do we have concrete use cases for using this zope.authentication outside of a Zope context? What would that look like? Do we really expect people to show up and say: "hey, I'll use this for my project that doesn't use zope.publisher at all!".
It can be very useful if someone wants to implement pluggable authentication system to use with zope.component/zope.security but with custom request implementations. However, it's hard for me to say if anyone will show up and talk about that use case, because 99% that I won't be that guy. :-) So, no "concrete use cases" yet.
We can also ask it in another way: if zope.authentication were not to depend on zope.publisher, would zope.principalregistry not depend on zope.publisher either?
Yes, zope.principalregistry does the adaptation of an abstract request object to ILoginPassword to get credentials and issue challenges, so if we provide an adapter for another request implementation, it will work fine without any changes. I can easily write a really simple adapter from webob.Request to ILoginPassword and use zope.principalregistry with it, without any zope.publisher/publication context.
What about zope.app.authentication and z3c.authenticator? (imagining any of their ZMI away for now). Would *those* packages then be useful independently from zope.publisher?
Currently, they are using some of implementation bits of zope.publisher, but I think, it's not a very big work to make them request type independent. The only possible difficulties I can think of is the implementation if loginform/cookie plugins.
I still feel bad about zope.publisher needing to know about authentication (in the dependency sense) where it doesn't today. Is that really true: does it today really not do anything with authentication?
Well, it implements the zope.security's IParticipation and has the "setPrincipal" method, but the principal is actually set by IPublication object. It also defines and implements the IHTTPCredentials/IFTPCredentials that allow to get login/password and initiate a login challenge, similar to the ILoginPassword, but request-specific. BTW, the classes in questions are the adapters from IHTTPCredentials/IFTPCredentials to the ILoginPassword. -- WBR, Dan Korostelev
Hey Dan, Thanks for your answer. Go ahead and make zope.publisher depend on zope.authentication. Could you document a summary of this discussion within the Python code that implements these adapters? (or the ZCML if you think that's better) As a general point, right now the whole idea to use alternate requests with most Zope Framework libraries is rather theoretical. It may very well be that at some point in the future we develop the priority to make as many Zope Framework libraries work independently from zope.publisher as possible, or perhaps directly port it to use webob. I think that will be the moment when the real head-scratching begins, and I'm not sure whether this move really helps prepare the way very much considering the scale of the effort involved. But do it anyway. :) Regards, Martijn
participants (2)
-
Dan Korostelev -
Martijn Faassen