Steps to Reproduce: 1. Construct and open a xhr GET to a CORS (allow-credentials enabled) basic auth endpoint, setting the Authorization header. 2. Open a new xhr with the same parameters, this time without setting the Authorization header. Actual Results: Second request fails with 401. Expected Results: Browser should have cached the authentication for the domain, as it does for non-CORS requests.
Can you please provide a complete test case? Some comments: 1. A CORS request without withCredentials set would not use cached credentials anyway. 2. I'm surprised that credentials passed via a custom Authorization header ever work on subsequent requests. I would not expect this to work, unlike credentials explicitly passed in XHR.open() call.
Note: I just added a test page on the bug report. Indeed, setting the Authorization header will not cache, even on same-domain requests. I guess my expectations were wrong there. Discussing this issue with the Mozilla guys, it seems the issue is CORS specifies that the username and password used on the `open` call should be discarded, which in practice makes CORS authorization uncacheable. The use case I have in mind is (quoting from my discussion over at Mozilla): "Take the use case of a website that uses a REST API which requires BasicAuth (everything goes over HTTPS): 1. website presents a form login, which is used to auth user against API; 2. JS performs XHR on API to verify auth; 3. Auth is cached by the browser, which allows the website to perform other requests during that session. While this works for same-domain, step 3 evidently does not work with CORS, since not `open` nor setting the headers will do the caching. Is this just not a valid use case for CORS? Only possible workaround I can see is to store form input in a session cookie to send on all CORS requests. Pros: lifetime is the same as regular browser auth caching Cons: credentials are easily readable on the machine I would appreciate any advice regarding this. " Regarding the CORS specification, I don't understand the rationale of discarding the credentials on the open call. I don't see what attacks does that prevent that cannot be achieved by using `setRequestHeader` for the Authorization (the spec is not very clear here). Regarding Webkit then, I guess the issue is whether it should support some form of caching for CORS credentials, is this a reasonable use-case, and if adhering to the spec makes sense there.
Will passing credentials with the cross-origin request work for you if you set withCredentials attribute to true?
Does not help(In reply to comment #3) > Will passing credentials with the cross-origin request work for you if you set withCredentials attribute to true? Does not help to cache the credentials in the `setRequestHeader` case, or to make Webkit use the username and password on the `open` case. Essentially, it seems it will only help when sending cookies?
Created attachment 261878 [details] Server side test case Attaching server side code just in case.
<rdar://problem/80290936>