[whatwg] Solving the login/logout problem in HTML

[Julian Reschke]

Ian Hickson wrote:
> On Wed, 26 Nov 2008, Julian Reschke wrote:
>> Ian Hickson wrote:
>>> ...
>>> As can be seen in the feedback below, there is interest in improving the So
>>> when you get to a page that expects you to be logged in, it return a 401
>>> with:
>>>
>>>    WWW-Authenticate: HTML form="login"
>>>
>>> ...and there must be a <form> element with name="login", which represents
>>> the form that must be submitted to log in.
>>> ...
>> For security reasons, I'd prefer that to be "the <form> element", 
>> instead of "a <form> element" -- having multiple copies of the name in 
>> the same document should be considered a fatal error.
> 
> Having multiple <form> elements with the same name is already an error.

Yes.

> I'm not sure what you mean by "fatal" error. The spec precisely defines 
> which form should be used in the case of multiple forms with the same 
> name. Could you describe the attack scenario you are considering?

If everybody UA is going to run an HTML5 parser as specified, then a 
problem is unlikely. I just don't believe this is going to happen. In 
*that* case, ambiguous login information is a problem, and a simple ans 
safe way to avoid this issue is to tell clients to abort when they 
detect the problem.

>>>> Yes, that's a simpler option. :-) (Provided that current browsers 
>>>> still ask for authentication even when given a 200 OK.)
>>> I don't think they do now, but it's something we can move towards.
>> I think asking for credentials when the status is 200 would be a bug.
> 
> 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.

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.

BR, Julian