[whatwg] Solving the login/logout problem in HTML

[Martin Atkins]

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):
> 
>    challenge = "HTML" [ form ]
>    form      = "form" "=" form-name
>    form-name = quoted-string
> 
> (There's no "credentials" value for this scheme, since the login is done 
> as a POST to a login script and then the server sets proprietary login 
> information, like a cookie using Set-Cookie.)
> 
> So when you get to a page that expects you to be logged in, it return a 
> 401 with:
> 
>    WWW-Authenticate: HTML form="login"
> 
> ...and there must be a <form> element with name="login", which represents 
> the form that must be submitted to log in.
> 

This idea has promise, but is it compatible with existing browsers?

The case where the only challenge included is HTML is probably okay, 
since browsers will at this point likely determine that they don't 
support any of the given schemes and just display the entity body. The 
only concern in this case is browser-provided default error pages for 
the 401 response, which can hopefully be suppressed in much the same way 
as sites suppress IE's default 404 error page by padding the response to 
take it above a certain filesize.

More bothersome is this case:
HTTP/1.1 401 Unauthorized
...
WWW-Authenticate: HTML form="login"
WWW-Authenticate: Basic realm="..."

Will existing browsers see Basic there and use that in preference to 
displaying the error page? I suspect the answer is "it depends". I 
recall that some browsers only use Basic if it appears first, or perhaps 
only ever use the first in the list, which would be great for the use 
case of supporting at the same endpoint HTML auth for browsers and some 
other mechanism for non-browser agents that can't render HTML. (For 
example, a Microformats parser may be able to parse HTML and extract 
data but not have a way to present usable forms to the user.)

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

HTTP/1.1 302 Found
Location: /login.php
WWW-Authenticate: HTML form="login"

Where in this case the form is assumed to be in the body of the resource 
at /login.php, not in the response body.

UI-wise I'm imagining that browsers would auto-focus, highlight or 
otherwise make available easily the nominated form once rendered. Is 
that what you were imagining?