- From: Mike West <notifications@github.com>
- Date: Tue, 06 Nov 2018 04:06:14 -0800
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/517/436230138@github.com>
> @mikewest would your "probably" statement in the minute be confirmed or clarified ? The proposal at this point, as I understand it, is that `fetch("https://cross-origin-thing/", {credentials: "include", mode: "cors"})` would reject with something like a `SecurityError` `DOMException` whose `message` was along the lines of: > The request specified a `mode` of "CORS", and included credentials. The response included `Access-Control-Allow-Origin: *`, which only succeeds for non-credentialed requests. Is that accurate? If that's the case, then I agree with @annevk that there's some risk in revealing the information that the resource would have allowed itself to be read if it had been requested without credentials, and that it does violate the philosophical boundary between a resource that has opted-into sharing its state cross-origin and one that hasn't. But I think that risk is fairly minimal, since the resource _did_ allow itself to be read if requested without credentials, and the developer could certainly try that out themselves to see what happens. This feels like a little sugar on top of an existing mechanism that doesn't seem to uniquely expose anything interesting from a security standpoint, but potentially gives developers/libraries the ability to know when a retry would be a reasonable thing to do. It seems like the smallest thing that could possibly work, and is certainly less invasive than creating new CORS modes. If developers are feeling this pain, it doesn't seem unreasonable to carve out this explicit signal for them. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/517#issuecomment-436230138
Received on Tuesday, 6 November 2018 12:06:40 UTC