[Zope-PAS] Challengers (and Zope 3)

[Jim Fulton]

Lennart Regebro wrote:
> Jim Fulton wrote:
> 

...

> The question was never about having multiple HTTP challenges. That is, 
> and has always been, a trivial excercise.

No, it isn't.  If there are multiple HTTP-based challengers, they
need to all return false so that they all run.  If there are any non-HTTP
challengers, they will run too, which will cause problems.

 > The problem is how to in a
> useful and simple manner let separate challenge plugins interact, and 
> let separate plugins each provide parts of those multiple challenges.
> 
> The conversation involved three people. At least two of them (Mark and 
> me) agreeed that wee needed multiple HTTP challenges. Mark and Tino 
> convinced me that doing that by letting separate plugins interact was 
> too complicated.

I don't think you are listening.  I saw lots of frustration on Mark's part
that he had a need that was being ignored.  I think Mark still feels
it is important to support multiple HTTP challenges, as do I.


>> Not for Zope 3. In Zope 3, it will generally not be the job of the 
>> plugins to set the body.
> 
> 
> Oh. OK, so, does that mean that inline-login forms are out of the question?

No. The unauthorized view is totally pluggable.  If we decide
we need PAS plugins to be able to output to the response, we'll
figure out how to do that. (In the future, I think we'll develop
richer APIs for influencing the response output, for example, to
support pipelining).  For now, we'll say YAGNI.

...

>>> Either plugins that ONLY set WWW-Authenticate headers return 0, and 
>>> are placed first in line. They can set 401 too, that's fine. A plugin 
>>> that redirects will make the client ignore those headers. So it's not 
>>> a problem.
>>
>>
>> That means that plugins that use HTTP authentication always lose if there
>> are any non-http challenges.  That's silly.
> 
> 
> Not at all. It is the challenger that returns "1" that "wins". 
> Basically, the challenger that sets the status or the body.

That doesn't work, because then one of the HTTP challengers needs to be
that one and it needs to be last among the HTTP chalengers. This is far
too brittle.

> Now, with Zope3, you say that the challenger should not set the body. 
> That makes things easier, and a challenger that sets the status could 
> break the loop.
> 
> for plugin in plugins:
>     plugin.challenge(request, response)
>     if response.status != 200:
>         break

A challenger might not work by setting the status at all, but it should
*still* be able to say that it did something.  It should be able to do
so in a way that allows other compatible challengers to work too.

Relying on assumptions about how a challenger works is waaaaay too
implicit.

> Hmmm. In Zope2 we could do
> 
> for plugin in plugins:
>     plugin.challenge(request, response)
>     if response.status != 200 or response.body:
>         break
> 
> That means, you can add WWW-Authenticate headers to your hearts desire, 
> but when you change the status or the body, things stop.
> 
> Hmm. Not bad. That could work!

No. Too implicit.

>>> We extend the HTTPBasicAuth to add more headers.
>>> All WWW-Authenticate challenges except Digest and Basic seem only to 
>>> be a simple string. That way one plugin does all the WWW-Authenticate 
>>> setting, and no intra-plugin fiddling is needed.
>>
>>
>> I have no idea what you are saying here.
> 
> 
> Let ONE plugin at a time do the challenge. If we are doing a 
> WWW-Authenticate challenge, make *one* plugin that does that. Adding 
> WWW-Authenticate several header in one plugin is trivial.

We don't want to make *one* plugin responsible for *all* HTTP-based
challenges. I don't want to have to support NTLM in a stanfard basic-auth
plugin, nor do I want to make the author of an NTLM challenger have to
support basic or digest (or other proprietary extentions).

> Because what made things complicated was the interaction. That is what 
> caused the headaches.

I've suggested a model that explicitly addresses the interaction,
by introducing the concept of "protocol" that defines domains of
interoperability.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org