[whatwg] Solving the login/logout problem in HTML
Martin Atkins
mart at degeneration.co.uk
Wed Nov 26 14:10:53 PST 2008
Julian Reschke wrote:
> Martin Atkins wrote:
>> 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="..."
>> ...
>
> Is that case relevant? Today, those sites do not support Basic (or
> Digest) at all, or only send the 401 for certain user agents and/or
> methods. So I wouldn't expect them to start adding the non-HTMLL auth
> challenge...
>
By that line of reasoning, you could equally argue that sites don't need
this authentication scheme at all since they do just fine without it today.
I think this new authentication scheme is most interesting when used in
conjunction with other schemes, because it allows the same endpoint to
be used for both browsers and other non-browser agents.
One use-case, which I hinted at in my message, is pages that contain
data annotated with microformats. These are useful both to browsers and
non-browser agents, but today it's cumbersome to use microformats on
pages that require authentication to view, since it is difficult for a
non-browser agent to figure out how to log in to an arbitrary site
without human intervention.
I went ahead and did some basic testing of this case, anyway.
For my initial test, I arranged for my server to send a response like this:
---------------------------------------------------
HTTP/1.0 401 Unauthorized
Content-type: text/html
WWW-Authenticate: HTML form="login"
WWW-Authenticate: Basic realm="test thing"
<html>
<head>
<title>Log in</title>
</head>
<body>
<h1>Log in</h1>
<form name="login" action="/login.cgi?return_to=/testauth.cgi">
<div>Username: <input type="text" name="u" /></div>
<div>Password: <input type="text" name="p" /></div>
</form>
</body>
</html>
---------------------------------------------------
This case didn't turn out so well:
* IE7: Displayed Basic login dialog
* F3: Displayed Basic login dialog
* O9.5: Displayed Basic login dialog
In all cases, hitting Cancel on the login dialog caused the body to be
rendered as a normal page, which is better than nothing but not really
ideal.
I swapped the ordering so that Basic came before HTML, but the results
were the same. (as you'd expect.)
I figured though that in most cases if your two types of clients are
browsers and non-browser clients, it's quite likely that the non-browser
clients will be using OAuth rather than Basic authentication, since that
seems to be the "big thing" right now. I swapped out "Basic" for "OAuth"
in my second WWW-Authenticate header above, and the results were more
promising:
* IE7: Rendered the response body as a normal page
* F3: Rendered the response body as a normal page
* O9.5: Displayed an error: "The server requested an authentication
method that is not supported."
I find Opera's error in this case to be strange since in the
supported-but-cancelled case it quite happily rendered my provided form,
yet in this case I can find no way at all to get my provided form to
show up.
Once Opera adds "support" for the HTML scheme -- even if that support
involves nothing more than just rendering the response body as-is --
then supporting HTML and OAuth at the same endpoint should sensibly
across all three of these browsers. (I don't have Safari available to me
for testing.)
Of course, this is only working because current browsers support neither
OAuth or HTML; it works equally well if you include only the OAuth
header and omit the HTML header, since the result is the same.
More information about the whatwg
mailing list