- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 4 Feb 2016 09:40:19 +1100
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Yves Lafon <ylafon@w3.org>, Tim Berners-Lee <timbl@w3.org>, Public TAG List <www-tag@w3.org>
Thanks, Jonas - that's (again) very helpful. One thing this brings to mind is the current discussion on an origin-level preflight: https://github.com/whatwg/fetch/issues/210 If such a thing were defined, it'd provide a more reasonable way for sites to opt into credentials (if the mechanism allows that). Cheers, > On 4 Feb 2016, at 5:17 am, Jonas Sicking <jonas@sicking.cc> wrote: > > On Tue, Feb 2, 2016 at 6:44 PM, Mark Nottingham <mnot@mnot.net> wrote: >> Hi Jonas, >> >> Thanks for all of the context, it's most helpful. >> >> Could you explain a bit more about how withCredentials fits in? >> >> AIUI, it works with Access-Control-Allow-Credentials (ignoring the interaction with Access-Control-Allow-Origin for now); >> >> 1) If both are false, the check succeeds and credentials aren't used. >> 2) If both are true, the check succeeds and credentials are used. >> 3) If withCredentials is false and ACAC is true, the check succeeds and credentials aren't used. >> 4) If withCredentials is true and ACAC is false, the check fails. >> >> ... as per <https://www.w3.org/TR/cors/#resource-sharing-check>. >> >> If that's a correct interpretation, the interesting one here is #3. What's not clear to me is whether this is an optimisation or if it's intended to prevent some sort of attack or information leakage. >> >> If it's an optimisation (to avoid the round trip to discover ACAC on what was a simple request), couldn't the browser take the presence of ACAC on the response as a signal that it should have included credentials, and reissue the request? Of course it's not optimal, but it would remove the *need* to set withCredentials to get interoperability. > > It is not to mitigate a threat, at least not primarily. > > It is to avoid having to issue two requests. I think calling it an > "optimization" is understating it a bit. > > Not only would issuing two requests many times likely be so slow that > people would likely opt to use other solutions, such as JSONP. > > The other problem is that for requests that have side effects, issuing > the request twice could of course be problematic. This applies to GET > requests as well unfortunately since unfortunately they in practice > often do have side effects. > > It's not clear to me how big this problem would be in practice though. > For request that has side effects and that uses cookies, it is likely > common that those cookies are used for authentication and thus issuing > the request without cookies would result in a denied request and no > side effects (maybe other than logging an error). > > So in that case issuing two requests, where the first one is without > credentials, would be fine. > > But if cookies are used for other things than authentication, then > issuing the request twice seems like it could easily be a problem. > > For that reason, I think re-issuing the request when an "ACAC: true" > is returned would be bad (not to mention likely not web compatible at > this point). > > All of this was debated while we did the initial CORS design. > > What I don't remember debating, and which might work, would be to add > a different header which explicitly has the meaning "if this request > was issued without credentials, please re-issue this request with > credentials". > > Then leave it up to the server administrator to make sure that the > initial, credential-less, request doesn't create side effects. > > > I could see some privacy concerns with this though. Say that website A > wants to use some REST API which website B provides. Currently website > A can do this without exposing to B that the user is using website A. > Simply issue CORS requests with .withCredentials is set to false. > > If we add a "please re-issue with credentials" header, then that means > that website B can now figure out the users identity, assuming the > user is logged in with B, by asking the request to be re-issued. > > Again, I don't know how big of a problem this would be. > > > I'm also not sure how popular this feature would be with developers. I > suspect most of them would prefer to use libraries which enable them > to set .withCredentials to true, rather than pay the cost of issuing > two requests. > > / Jonas -- Mark Nottingham https://www.mnot.net/
Received on Wednesday, 3 February 2016 22:40:54 UTC