[Zope-PAS] Re: [RFC] Extending CookieAuthHelper

[Chris McDonough]

On Thu, 2004-11-18 at 16:41 +0100, Jens Vagelpohl wrote:
> On Nov 18, 2004, at 16:09, Zachery Bir wrote:
> 
> > On 2004-11-18 09:59:05 -0500, Jens Vagelpohl <jens at dataflake.org> said:
> >
> >> It seems that instead of the login method calling updateCredentials 
> >> on the CookieAuthHelper itself, it should inform the PAS instance so 
> >> that the plugins registered for updateCredentials can fire. Am I 
> >> overlooking something?
> >
> > That sounds reasonable to me. Tres and I were discussing that many of 
> > the plugin points need to be surfaced at the PAS level, so it can fire 
> > any interested parties.
> 
> There are probably a myriad more or less complicated ways to make this 
> happen. One simple way could be to talk to the plugin registry itself 
> and call "listPlugins" with the desired interface to retrieve the 
> active plugins and call updateCredentials on each. Does that sound like 
> a reasonable thing to do inside a plugin (because only PAS itself 
> seeems to work that way now)?

Do we really want to have a plugin call all of its respective peer
plugins' updateCredentials methods during a challenge?  I've been in
places like this before, and it usually turns into a bughunt.

The challenge plugins are allowed know the protocol they're used for (is
there any other protocol than 'http' ?).  Maybe we should also make the
credentials update plugins also know which protocol they're updating.  

The PAS object during a challenge would temporarily store the results of
all the challenge attempts on a per-protocol basis (maybe somewhere in
the request).

The challenge plugin would never call updateCredentials method on PAS.
Instead, we'd provide a getCredentialsForProtocol method on the PAS
object that returns the data collected for a particular protocol.

Then the IUpdateCredentials plugin could ask PAS for the 

creds = pas.getCredentialsForProtocol(self.protocol)
... do update ....

- C