Re: ISSUE-13: suggest closing

Hi John,

On Fri, Aug 21, 2009 at 4:29 PM, John Kemp wrote:
>
> Julian Reschke wrote:
>>
>> John Kemp wrote:
>>>>
>>>> The spec currently says:
>>>>
>>>> "HTTP 401 responses that do not include a challenge recognized by the
>>>>  user agent must be processed as if they had no challenge, e.g.
>>>> rendering the entity body as if the response had been 200 OK.
>>>
>>> This feels odd - as if a new HTTP authentication mechanism (ie. as those
>>> defined in RFC)2617 has been developed, but which is not advertised in
>>> the response from the server, or is advertised but not understood by the
>>> user-agent. That seems to defeat the purpose of RFC2617 and the
>>> requirement that the user-agent MUST "choose to use one of the
>>> challenges with the strongest auth-scheme it understands".
>>
>> Could you elaborate where you see a conflict?
>
> My understanding of 2617 is that if some number of mechanisms are specified
> in the WWW-Authenticate header (say "cookie, digest, basic") and the
> user-agent knows only "basic" and "digest" schemes it MUST choose the
> strongest of those schemes. It cannot "choose" to follow a scheme that it
> does not know, for example. There is nothing in 2617 that suggests the
> user-agent should simply defer to the user if it doesn't understand one
> mechanism (but understands another) either.

In this case, the condition "do not include a challenge recognized by
the user agent" evaluates to *false* (it does include two challenges
recognized by the UA in this case).
This is different from "include a challenge not recognized by the user
agent" which you seem to have mistakenly understood.

>>>> Browsers do not display the text/html response body of a HTTP 401
>>>> response, instead, they just pop up a modal authentication dialog (until
>>>> "cancel" is pressed).
>>>
>>> I regard the above as being correct RFC2617 behaviour. If we want to
>>> allow form-based login via an RFC2617-compliant mechanism, shouldn't we
>>> actually define an HTTP authentication mechanism for it?
>>
>> Yes, we should.
>>
>> The latest activity on this is Thomas Broyer's
>> (<http://hg.ltgt.net/http-cookie-auth/>,
>> <http://tools.ietf.org/html/draft-broyer-http-cookie-auth-00>), and it would
>> be great if more people would help with that.
>
> Yes, that document looks to be a step in the right direction. I will take a
> more detailed look.

Note that contrary to what I said a few months ago on the http-auth
and httpbis lists, I'll add –as soon as I find enough time to do so,
which might not be before a few days or even weeks– a mechanism to
allow UAs to authenticate without knowledge of the response body
format (i.e. add username-field-name and password-field-name, or
similar, parameters to the challenge and define how to use them
–namely issue a POST request to the form-action with
application/x-www-form-urlencoded request body–; in other words, in
most cases, somehow "duplicate" the text/html form in the cookie
challenge).
...but this is a discussion for the http-auth list (feel free to mail
me in private if you prefer).
I'll also add a new 3xx status code for SSO use cases (think Google
Account, JA-SIG CAS, Shiboleth, etc.). A 303+WWW-Authenticate would
work now in all major browsers but it lacks the "you need to
authenticate" semantics...

> I can see that a user-agent wouldn't necessarily need to understand the
> contents of the Cookie challenge in order to give the user the chance to
> authenticate, although it would seem better if the user-agent _did_
> understand the mechanism rather than blindly presenting the form to the
> user.

The goal is backwards compatibility (to date, only Opera pre-10 shows
an error page instead of displaying the response body) while making
cookie/form auth RFC2617 compliant.
It would of course be better if UAs would treat those cookies a bit
differently than others (i.e. when I tell my browser to "clear
authentication information", it would also clear those cookies).

-- 
Thomas Broyer

Received on Friday, 21 August 2009 14:55:44 UTC