[Zope-PAS] Checked in the Challenge implementation.

[Lennart Regebro]

Mark Hammond wrote:
> My apologies - however, I was working against and talking about that code as
> supplied by you in mail a day or 2 before you checked it in.  I attach it
> here again (with a couple of small changes)

I think there should only be minor differences, but I'm don't remember 100%.

>>I'm convinced it works, and will remain
>>convinced it works until you make some kind of effort to tell
>>me why it is not working. Have you even tried it?
> 
> I did try it - that is how I was able to tell you specifically how the
> result code handling of the implementation was my primarly issue.  I was
> speculating about how redirect based challengers would interact as I have no
> working example, but not about 'challenge/response' based ones (as we now
> have 2 - my example + HTTPAuth)
 >
> 
> All I am trying to do is make my plugin work and interact with existing
> schemes - I have no interest in creating work for works sake, or for making
> PAS somehow more to my "liking". I apologize that I have been sounding
> frustrated - my intention is not to antagonize, but I do feel I am having
> trouble communicating my issues, even when backed up with code.  The
> frustration results from my inability to express the issues better than what
> I have.
> 
> 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)
 >
> As supplied, the example does redundantly set the 401 (else it does not work
> when HTTPAuth is disabled), but does not set the body (to demonstrate the
> empty content in that case).  You can verify this by disabling HTTP auth and
> enabling the example auth, then use your browser to try and view a
> restricted page.


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.

> Is it your intention for all challengers to set the 401 status and a
> resulting message body?.

No. Only the ones that work standalone.

> I am also confident that this scheme will not work "nicely" with redirection
> based challengers - but until I actually have some redirection based code I
> can test and experiment with, I can't give specific examples.

CookieAuth now does redirection, so if you check out the trunk you 
should have an example there.

> 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.

> 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.