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
