[whatwg] Solving the login/logout problem in HTML

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.