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?
