[whatwg] Solving the login/logout problem in HTML
t.broyer at gmail.com
Wed Nov 26 03:47:46 PST 2008
On Tue, Nov 25, 2008 at 6:26 AM, 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):
I came to the same conclusion and already implemented it (with a
custom application-specific scheme) in an Enterprise app (the custom
scheme accepts both HTML form, i.e. cookie, and an Authorization
request-header –we're using it for XMLHttpRequests to "bypass" any
cookie and therefore allow more than one "user session" in the same
> challenge = "HTML" [ form ]
> form = "form" "=" form-name
> form-name = quoted-string
RFC2617 states that "The realm directive (case-insensitive) is
required for all authentication schemes that issue a challenge."
On Tue, Nov 25, 2008 at 6:54 AM, Martin Atkins wrote:
> This idea has promise, but is it compatible with existing browsers?
It works great in IE6/7 (I think I tried IE8b2 but I'm not sure),
Safari 3(Windows) and FF2/3.
Google Chrome pops the classic auth dialog, and when you dismiss it it
"correctly" shows the HTML form.
Opera 9 (don't remember the actual version number but I try to keep it
up-to-date with the "stable" versions, i.e. no beta version) shows an
error page saying something like "unsupported authentication scheme".
> There's also one more case to consider. Many sites react to an unauthed
> request by *redirecting* to the login page.
That would have to be changed to a 401 if you want to become a "good citizen".
On Wed, Nov 26, 2008 at 11:41 AM, Julian Reschke wrote:
> Ian Hickson wrote:
>> Even in the asynchronous way mpt suggested? I think it would go a long way
>> towards addressing the limitations of HTTP authentication. One of the great
>> benefits of HTML authentication forms is that they can be made available in
>> the equivalent of a 200 OK situation as opposed to only in the equivalent of
>> a 401 situation.
Varying the response depending on the authenticated user (or
no-authenticated-user case) is bad practice already (even if more than
widely used, e.g. in e-commerce).
You should either put the "session id" in the URLs (i.e. create new
temporary resources that only one user is authorized to access and
that will "expire"/disappear when the user logs out, to speak in ReST
terms), or put the user id in the URL (if the state is shared between
"sessions", including simultaneous ones; i.e. create user-specific
independently of the rest of the page (the page that is served to all
users, authenticated or not).
> You can already handle the case of content that's available unauthenticated,
> but would potentially differ in case of being authenticated by adding
> Vary: Authorization
> to a response.
I seem to recall Roy T. Fielding arguing *against* that when we were
discussing user-specific service documents in the Atom Protocol group.
More information about the whatwg