[Zope-PAS] Checked in the Challenge implementation.

[Mark Hammond]

> > The attached example does work correctly only if it
> > explicitly sets the HTTP
> > status and body.  If HTTPAuth is disabled and it does not
> > set the HTTP
> > status, a '204 No content' is returned.  If the body is not
> > set, 401 with an
> > empty body is (which is no use for clients which do not
> > understand the auth
> > scheme).  If HTTPAuth is enabled, both challengers set the
> > response and body
> > (with only one winning)

> For your plugin to work standalone, as you mention, you have to set a
> body and you have to set the status to 401. This is correct. In that
> case, you should also return a 1, so that no further challengers are
> being called.

I believe it rare that my plugin will work truly "stand-alone".  It is quite
likely that some site admins will want it to interoperate with HTTP auth,
and some site admins will *not* want HTTP auth.

To be 100% clear - my requirement is that the site admin have complete
control over the auth schemes used, and how they interact.  Running
"stand-alone" is only one such scenario.  Running alongside http auth is
another.

> > Is it your intention for all challengers to set the 401 status and a
> > resulting message body?.
>
> No. Only the ones that work standalone.

You mean any ones that may or may not need to work with HTTP auth?

Assuming we want to give the site admin that control, as far as I can tell,
that means "all challenge/response style challengers"?

> > Once you
> > install my sample with your working CAS redirector and try
> > and imagine a
> > site where they must *all* interact, you may begin to see
> > what my concerns are.
>
> Well, that is exactly what i said when I mentioned to you
> that we could
> not always run through all challengers. It would make a mess
> of things.
> And that is why I added the "if - break" to the loop, so that
> challengers that redirects or sets the body can return 1, to
> say that no more challengers should be called.
>
> > Alternatively, you may be able to explain why my concerns are
> > unfounded.
>
> They aren't. The concerns are well founded, as I explained the 23rd.
> Which is why plugins that set the body or redirect should return 1.

By "interact", I meant "work together".  The best I can tell, as soon as a
redirect plugin is used, all challenges are lost.

For the site admin, this means that they can never have both challenge *and*
redirect based logins working at the same time - the redirect based one will
*always* clobber the challengers.

I agree that we can not give an ideal result in all scenarios, but believe
we can do better than nothing.

> > Another alternative is that PAS does not allow site admins to
> > mix challenge/response schemes with web based redirection
> ones - that would
> > be good to know and have documented for other people investigating
> > UserFolder implementations.
>
> Well, as mentioned, depending on client implementation, this may not
> work. And then of course, this should be noted in the developers docs.
> But it needs to be tested as well so we know that in fact it
> doesn't work.

I believe we understand why it doesn't work - the first 'redirect' based
challenger destroys any previously setup challenges.

Another issue:
Did you have a chance to play with the sample?  It is possible to
demonstrate that in some cases, the original "response._unauthorized()" is
still called, which still adds a "www-authenticate: basic" header to the
response.  Thus, even when HTTP auth is disabled, basic authentication
headers are seen by the client.

Do you have any suggestions about that?  My plugin can do a 'setHeader'
rather than an 'addHeader', but  the HTTP auth plugin also does setHeader
and as discussed, it must be last - so it seems I have a solution for
working with or without HTTP auth, but not one option that allows both.

Thanks,

Mark