Bug 109533 – CORS requests don't cache authentication

• Component: WebCore Misc.
• Status: UNCONFIRMED

[Paul Eipper]

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.

[Alexey Proskuryakov]

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.

[Paul Eipper]

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.

[Alexey Proskuryakov]

Will passing credentials with the cross-origin request work for you if you set withCredentials attribute to true?

[Paul Eipper]

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?

[Paul Eipper]

Created attachment 261878 [details]
Server side test case

Attaching server side code just in case.

[Radar WebKit Bug Importer]

<rdar://problem/80290936>