[Bug 15418] sort out HTTP auth

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15418

--- Comment #16 from Hallvord R. M. Steen <hallvord@opera.com> ---
I've added some tests:

http://w3c-test.org/web-platform-tests/submissions/103/XMLHttpRequest/send-authentication-basic.htm
- asserts that browsers should *not* send Authorization until they've seen a
401 challenge, should use user name and password from open() if they have
received 401, should not pass on 401 response details to JS

http://w3c-test.org/web-platform-tests/submissions/103/XMLHttpRequest/send-authentication-basic-setrequestheader.htm
- asserts that if setRequestHeader() is used to add an Authorization header, it
should be sent immediately whether or not there has been a 401 challenge.

http://w3c-test.org/web-platform-tests/submissions/103/XMLHttpRequest/send-authentication-basic-cors.htm
- asserts that user name and password from open() should not be used in CORS
requests (even if the JS sets withCredentials and the remote server explicitly
allows both credentials and Authorization header). This is obviously a
limitation that's based on these arguments as far as I can tell: 

 * because it might add some complexity to implementations
 * because we feel like limiting it :-p

http://w3c-test.org/web-platform-tests/submissions/103/XMLHttpRequest/send-authentication-cors-basic-setrequestheader.htm
- asserts that when using setRequestHeader() to add Authorization: header, the
header should be sent if the remote server allows Authorization headers. This
would allow a (less convenient) way to use HTTP Auth in cross-origin requests
even if we disallow open() user/pass. Fails in all current browsers.

So, largely, implementations don't let you do cross-origin XHR auth at all..

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 16 May 2013 14:18:44 UTC