[Webkit-unassigned] [Bug 109533] CORS requests don't cache authentication

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=109533


Paul Eipper <lkraider+webkit at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://lkraider.eipper.com.
                   |                            |br/tests/cors/authcache.htm
                   |                            |l




--- Comment #2 from Paul Eipper <lkraider+webkit at gmail.com>  2013-02-13 13:00:14 PST ---
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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.