[Zope-PAS] Challengers (and Zope 3)

Jim Fulton jim at zope.com
Fri Oct 1 09:25:04 EDT 2004

Lennart Regebro wrote:
> Jim Fulton wrote:
>  > The purpose is to support protocols, like HTTP, that allow
>  > multiple challenges, while not mixing challenges across protocols.
> Well, that is possible anyway, but I guess you want to allow different 
> plugins to interact and provide the different challenges, which is what 
> we discussed a week ago, and which everybody thought was to complicated 
> and privided lot's of headaches and back-aches. ;)

First, as I said before, I think Mark has a valid use cases that is
supported by the HTTP authentication spec.

Second, AFAICT, the conversation involved mainly two people, hald of whom
thought that support of multiple HTTP challenges was important.

> Well, maybe. Or Firefox simply goes through the WWW-Authenticate in 
> order and tries them out, and doesn't care that they are duplicates. 
> Which makes perfect sense.

No, it doesn't.  The spec says that the client should use the strongest
type of challenge that it understands.  As I said, I'd like to try this
myself (or get sprinters to try it) and see how browsers behave in the
presense of two different kinds of challenges.

 > Also, if it gets a challenge it doesn't
> understand: like NTLM, significantly enough, it will throw up a dialog box.

That is not correct behavior.


> "Challenges can be mixed if they come from the same protocol.
> They cannot be mixed otherwise."


> Your implementation will in that case mean that the LAST plugin to set 
> the body will override earlier plugins bodies. Which is greatly 
> confusing, since in all other cases it is the FIRST plugins that decide. 

Not for Zope 3. In Zope 3, it will generally not be the job of the plugins to
set the body.

> Also, it requires all plugins to play nicely with all other plugins, and 
> I'm not sure I like that.

It requires plugins from the same protocol to play nicely with one another.

> One possible implementation that solves those issues is this:
> for plugin in plugins:
>     status, headers, body = plugin.challenge(request)
>     if not status or status == 200: # This plugin did not challenge
>         continue
>     if response.status == 200: # This plugin is the first to challenge.
>        response.setStatus(status)
>     elif status != response.status: # A status is already set.
>         # ignoring all plugins that do not go with this status:
>         continue
>     if body and response.body: # Somebody already set the body.
>         # Ignoring this plugin
>         continue
>     if body:
>         response.setBody(body)
>     # This plugin agrees with the status and does not override the body:
>     for key, value in headers.items():
>          response.addHeader(key, value)

I think this is way too complicated.

> Note that none of the plugins fiddle with response any more.
> And as you see, this DOES get kinda complicated. And figuring out why 
> the heck your plugin isn't challenging is a, well, challenge. ;)

Right, which is why it isn't very appealing.

It also assumes to much about the ways the challengers work.

> So, I'm gonna suggest this implementation:
> for plugin in plugins:
>     if plugin.challenge(request, response):
>         # This plugin challenged:
>         break
> Simpler eh? ;-)

This is where we started.

> So, how to get several WWW-Authenticate header with this implementation? 
> Well, two ways:
> 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.

> OR, even simpler:
> 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.

> Thoughts?

The suggestion I proposed is only a little bit more complicated than
the original algorithm and addresses the need to support multiple
challenges for HTTP in a straightforward way.  I want to experiment
with it to see how well it works as the next step.


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

More information about the Zope-PAS mailing list