- From: Martin Atkins <mart@degeneration.co.uk>
- Date: Wed, 26 Nov 2008 14:10:53 -0800
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.
Received on Wednesday, 26 November 2008 14:10:53 UTC