On 05 May 2014, at 11:38, Tobias Mueller muelli@cryptobitch.de wrote:
Hi.
On Mon, May 05, 2014 at 10:31:56AM +0200, Ján Máté wrote:
it is nice that at least Firefox tries to fix these issues, but until these features are not supported at least by Gecko + Webkit browsers (FF + Chrome, Safari, ...) there is no reason to use them.
I don't agree with that sentiment, but everbody has their preferences...
In any case, it seems your assessment of the Web browsers handling the HTTP authorization header is incomplete, cf. http://codereaper.com/bugspray/javascript/xmlhttprequest/httpauthentication/ and https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#the-send%28%29-method
If authentication fails, source origin and the request URL are same origin, Authorization is not in the list of author request headers, request URL's username is the empty string and request URL's password is null, user agents should prompt the end user for their username and password.
Otherwise, if authentication fails, user agents must not prompt the end user for their username and password.
The problem is that JavaScript client differs from the standard browser behaviour. If you open a web site protected by basic auth then you make a request, get the "WWW-Authenticate" header and then send your credentials. With JavaScript you simply sends the request directly with the Authorization header (without making a prior request) and if the authorization fails then you get the "WWW-Authenticate" header in the response ... It is maybe not compliant with the specification(s) (I don't know) but it simply works this way (real world experience) ...
JM
Cheers, Tobi