views:

822

answers:

3

I use XMLHttpRequest and basic-auth to access application interface. Password is temorary and is generated by other request, so it expires after some time.

But browser (Firefox least) keep using old one, failing and showing login popup. If i suppress popup by returning 403 for requests with X-Requested-By and wrong password, mozilla never tries to use new password (firebug shows new password in request, server receives old).

Problem can be evaded by adding random 'salt' to username (and stripping it at server side), but is there better way to force XMLHttpRequest use provided password instead of cached?

A: 

Hi,

I used to have the similar problems sending values using GET but not with POST.

Regards.

ATorras
A: 

401 responses include an "authentication domain," which defaults to the all URLs on the server (see RFC 2617). The browser is expected to provide the same credentials to any challenge from the same domain.

Since you're already generating an expiring password, why not simply turn it into a token that has to be appended to every request? For example an SHA1 hash of the username, perhaps salted with a timestamp. I'm assuming that you'll use this as a key on the server to retrieve the user's data.

kdgregory
Didn't you mean 401 responses?
ymv
you're correct - I've updated
kdgregory
A: 

I'm experiencing the same problem: Firefox refuses to clear the cache and accept the new password, despite Firebug showing the new passport being sent! That looks like a bug to me. You wrote that changing the username with random salt actually prevents the problem, right? Could you detail that a bit more? why is that not an acceptable solution?

Thanks! Emanuel

HTTP auth aparently wasn't intended to be used this way (non-interactive login), so it's more of protocol limitation than bug. Salting works fine, but it's ugly (but not outright protocol misuse, as using 403 responses instead is).
ymv