Don't bother reading unless you give at least a quarter of a shit about XMLHttpRequest and HTTP authentication.
Here's a stupid geek trick. The correct login information for this
is user="user", password="password". Give it the wrong password [it will say something like 401 Unauthorized, user="user", password="bogus"]. Then give it the right password and try again - it will keep sending the wrong password. This happens in both Firefox and IE; Safari has a slightly different bug.
Here's the sitch: I have an XMLHttpRequest going out to a password-protected resource. The credentials are supplied by the user and thus they are likely to be wrong some of the time. The script is designed to gracefully handle authentication failure - specifically, I want to avoid the crappy infinite HTTP authentication dialog box loop. I'd think that this issue would come up from time to time, but I guess it doesn't because this is really hairy:
XMLHttpRequest
states "If authentication fails, user agents SHOULD prompt the users for credentials."
To work around this, Paul James
suggests returning 401 Unauthorized without the mandatory WWW-Authenticate header. In theory, this tells the browser to stop trying and forget the password. The browser does, in fact, stop trying, but it also goes into a weird undefined state where it continues to issue the old [incorrect] password despite instruction to the contrary. [Safari instead puts up the dialog on the next request, even if credentials are provided.]
HTTP/1.1
states "If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information." - ie, reissue the same challenge to indicate to the browser that it should give up. As near as I can tell, not a single browser has ever done that.
HTTP/1.1 also gives us 403 Forbidden: "Authorization will not help and the request SHOULD NOT be repeated." This response has the same bizarre effects as 401 without WWW-Authenticate.
I'm actually kind of an AJAX newb, so ... does anyone have any recommendations?
- Z
You could easily implement that with my javascript method. It is using javascript to md5 the data before sending. If you sent some salt from the server you could easily mix that in too and have a total custom blend.
Are you getting Leopard jitters yet!!
The problem with cleartext and Basic is well-known: you can recover the password. md5 is better because you can't recover the original password. But the server never asks for the original password. It asks for md5(password), which is passed around in cleartext on the wire.
With HTTP Digest, the server sends a random session nonce to the client. The client adds its own random request nonce and sends back (r-nonce, md5(password, s-nonce, r-nonce)). The effect is that the hash that's sent to the server is different for every request. There's actually more that goes into it that also prevents someone from using an old hash.
Will clean up code & post this afternoon.
- Z
HTTP digest is essentially md5 encryption. :::link:::
Can you post the source so we can see it or send it to me.