[Zope-PAS] Checked in the Challenge implementation.

[Mark Hammond]

First email:
> > Surely PAS is so
> > people can plug other authentication services.
>
> Not only. PAS is also there to hande the challenge mechanism, and the
> reasonably, it should handle the challenge mechanism. And one
> of the use cases that needs to be supported is redirecting.

As I said in my most recent mail, I believe we are abusing the concept of
'challenge' in trying to redirect to a login page.  'challenge' is well
suited to initiating a traditional challenge/response negotiation.

We do need to support redirection to a login page, but I'm not sure that
should be implemented as a 'challenge'.

> > we have no working baseline at all.  Do you have any
> > working challenge implementations at all?
>
> Yes, on my hard disk.

I just sent one that can be on everyone's hard-disk :)  Did you have a
chance to have a look at it, and see how your new code fits in that scheme?

> But since this is the third major
> effort from my part of making one, and the previous
> two has had cases where it did not
> work, i think it is ueful to make sure we understand the use cases
> before I check in yet another non-working challenge implementation.

I would have agreed <wink> - but in your next mail:

> I just checked in yesterdays suggested challenge implementation.

I have already pointed out this doesn't work for me for a couple of reasons
(and even supplied a sample implementation to demonstrate - I'm not sure
what more I can do):

> WWW-Authenticate: NTLM header, and then returns 0, and lets the next
> plugin do it's stuff. That next plugin could be
> HTTPBasicAuthHelper, for
> BasicAuth or maybe a plugin for in-place login.

That doesn't work.  HTTPBasicAuthHelper sets the page text, the response,
and returns True.  By asking NTLM to *just* set a header and rely on
HTTPBasicAuthHelper means NTLM could not work *without* HTTP auth.  This is
most certainly a requirement, as NTLM auth is 'silent', where HTTP auth
always displays a logon dialog.

It also doesn't handle that scenario in my most recent mail:

> However, let's assume a site actually *wanted* to prefer HTTP
> authentication, and if that failed, fall back to a web-based login screen.

How would that be implemented using the current setup?  As soon as we
redirect, we have lost all the challenges - even if they came earlier.
Which means that we are limiting the user to either HTTP logon *or* redirect
based - but never both.

But even with that constraint, the current code doesn't even allow my NTLM
implementation to interact correctly with HTTPBasicAuthHelper.

Mark.