[Zope3-dev] Is someone going to do a LoginManager-alikefor Zoipe3?

[Tres Seaver]

On Thu, 2002-03-21 at 20:40, Phillip J. Eby wrote:
> Wow.  Now I *know* I'm out of date.  I've never seen type assertions in 
> interfaces before this message!

I was using an experimental notion that Jim, Stephan, and I kicked
around last week.
> 
> This looks pretty well thought out.  I have only a few comments.
> 
> First "IAuthenticationService" seems to be a pure data object, with no 
> actual *service*.  Shouldn't it just *do* what's laid out in the 
> "getPrincipals()" function?  Otherwise it looks like it's just a 
> configuration object and shouldn't really exist on its own.

Some services exist primarily to function as registries of other
components.  While I agree that the 'getPrincipals' implementation
I sketched out seems like a logical method of the service, I was
unsure whether to mix those responsibilities.
 
> Also, I'm wondering how one distinguishes between output 
> principals...  suppose you have both an Anonymous principal and an 
> authenticated one?  (But here I'm probably showing my Zope 3 ignorance.)

Matt and I had tossed around the idea that a credential would have some
"trust level" associated with it (harking back to one of Chris
Petrilli's ideas).  If every principal had a 'getCredential' method, and
every credential could be queried (or adapted) to get a "trust info"
object, then I think both this question and the "only if SSL" one would
work.
 
> Something which was useful in Zope 2, but may not be relevant here, was the 
> use of a chaining approach within the lists of user sources (identifiers) 
> and login methods (extractors).  This allowed one to create login methods 
> which could check for additional credentials before granting a 
> login.  (E.g., fail if the user wasn't  using SSL.)  I see how one could do 
> that with this architecture, but combining such rules requires writing a 
> custom "identifier" rather than simply stacking primitives.  Still, I don't 
> see a way to create such a chain of responsibility here and still support 
> all of the other features this architecture offers.

Hmm, I guess I was thinking that each "identifier" would have access to
the complete set of credentials for the request.
 
> How are the subjects of logout and credential changes handled?  It's 
> unclear to me how one could find one's way to the right credential 
> extractors to tell them that credentials (e.g. a user password) was 
> changed, or that the user wishes to log out.  I think it would be very good 
> if we could address these items, as they commonly required kludging in Zope 
> 2 without LoginManager.  Under LoginManager, one can say 
> AUTHENTICATED_USER.logout(), for example.  What would be the equivalent here?

Good points.  In HTTP, dropping credentials must essentially involve
adding a response header;  we might need to extend the
ICredentialExtractor interface to allow delegation from the service to
one or more extractors, e.g.:

  def dropCredential( credential, request ):
      " Remove 'credential' from the request / response. "
      credential.assertType( ICredential )
      reqeust.assertType( IRequest )

      return Result( type=Boolean )

The first extractor which returns true stops the process, perhaps?

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com