- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 26 Nov 2008 11:41:05 +0100
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
Received on Wednesday, 26 November 2008 02:41:05 UTC