2009/3/12 Martijn Faassen <faas...@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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )