[Zope-PAS] Checked in the Challenge implementation.

[Tino Wildenhain]

Hi,

On Mon, 2004-09-27 at 11:34, Lennart Regebro wrote:
> 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.

Maybe we could simulate REQUEST.RESPONSE for the actual challenger
and have a rule like this:

Challenger can response.setHeader/Status like usual scripts in
publisher context if it returns something (if return value
is true) then the challengers output overwrites any currently
_setBody value. This way we could call multiple challengers
in turn, each can work on the headers and only the last
challenger which is interested in HTML output would win
on this part.