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

> 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

BTW, the classes in questions are the adapters from
IHTTPCredentials/IFTPCredentials to the ILoginPassword.

WBR, Dan Korostelev
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to