[whatwg] Solving the login/logout problem in HTML

[Thomas Broyer]

On Tue, Nov 25, 2008 at 6:26 AM, Ian Hickson wrote:
>
> It seems to me that the first limitation of form authentication could be
> removed by inventing a new WWW-Authenticate challenge that means "reply to
> the form in the page". I have now specified such a value in HTML5 (since
> it is specific to entity bodies that contain HTML forms):

I came to the same conclusion and already implemented it (with a
custom application-specific scheme) in an Enterprise app (the custom
scheme accepts both HTML form, i.e. cookie, and an Authorization
request-header –we're using it for XMLHttpRequests to "bypass" any
cookie and therefore allow more than one "user session" in the same
"browser session").

>   challenge = "HTML" [ form ]
>   form      = "form" "=" form-name
>   form-name = quoted-string

RFC2617 states that "The realm directive (case-insensitive) is
required for all authentication schemes that issue a challenge."


On Tue, Nov 25, 2008 at 6:54 AM, Martin Atkins wrote:
>
> This idea has promise, but is it compatible with existing browsers?

It works great in IE6/7 (I think I tried IE8b2 but I'm not sure),
Safari 3(Windows) and FF2/3.

Google Chrome pops the classic auth dialog, and when you dismiss it it
"correctly" shows the HTML form.

Opera 9 (don't remember the actual version number but I try to keep it
up-to-date with the "stable" versions, i.e. no beta version) shows an
error page saying something like "unsupported authentication scheme".

> There's also one more case to consider. Many sites react to an unauthed
> request by *redirecting* to the login page.

That would have to be changed to a 401 if you want to become a "good citizen".

On Wed, Nov 26, 2008 at 11:41 AM, Julian Reschke wrote:
> Ian Hickson wrote:
>>
>> Even in the asynchronous way mpt suggested? I think it would go a long way
>> towards addressing the limitations of HTTP authentication. One of the great
>> benefits of HTML authentication forms is that they can be made available in
>> the equivalent of a 200 OK situation as opposed to only in the equivalent of
>> a 401 situation.

Varying the response depending on the authenticated user (or
no-authenticated-user case) is bad practice already (even if more than
widely used, e.g. in e-commerce).
You should either put the "session id" in the URLs (i.e. create new
temporary resources that only one user is authorized to access and
that will "expire"/disappear when the user logs out, to speak in ReST
terms), or put the user id in the URL (if the state is shared between
"sessions", including simultaneous ones; i.e. create user-specific
resources), or use IFRAMES and/or JavaScript to load the varying parts
independently of the rest of the page (the page that is served to all
users, authenticated or not).

> You can already handle the case of content that's available unauthenticated,
> but would potentially differ in case of being authenticated by adding
>
>  Vary: Authorization
>
> to a response.

I seem to recall Roy T. Fielding arguing *against* that when we were
discussing user-specific service documents in the Atom Protocol group.


-- 
Thomas Broyer