W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2008

[whatwg] Solving the login/logout problem in HTML

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 26 Nov 2008 10:12:44 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0811261010240.17401@hixie.dreamhostps.com>
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.

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?


> > > 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 26 November 2008 02:12:44 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:07 UTC