Restrict CORS wildcard+credentials combination for http(s) only.

Restrict CORS wildcard+credentials combination for http(s) only.

CORS-with-credentials are only defined for http(s) resources.

Chromium uses Access-Control-Allow-Origin: * with the intention of
whitelisting resources at certain origins for use in XMLHttpRequest and
images with canvas.
When the includeCredentials flag is set, these requests are blocked, even
though the term "credentials" makes no sense for data:/chrome-extension:-URLs.

This CL relaxes the wildcard check for non-http(s) resources, so that implementors
can choose to use CORS regardless of whether credentials were requested.

BUG=315152
TEST=Layout tests are already in CL https://codereview.chromium.org/54173002/

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=169391

[robwu, 2014-03-10 23:08:04]

This patch has no tests, because the tests will only be available once the two
CLs in http://crbug.com/308768#c9 get accepted.

[abarth-chromium, 2014-03-11 00:52:52]

Why is the includeCredentials flag set?

[abarth-chromium, 2014-03-11 00:53:30]

It seems dangerous to have this whitelist here...  I guess we have a registry of
CORS-enabled schemes, so it isn't so bad, but I can imagine adding a new scheme
in the future that supports credentials and getting in trouble here.

[robwu, 2014-03-11 09:20:11]

On 2014/03/11 00:52:57, abarth wrote:
> Why is the includeCredentials flag set?

This flag is set by calling code, to signal that credentials are to be included
in the request, e.g. via <img crossOrigin> or XMLHttpRequests's
"withCredentials" property. (see also
http://www.w3.org/TR/cors/#access-control-allow-credentials-response-header)

On 2014/03/11 00:53:30, abarth wrote:
> It seems dangerous to have this whitelist here...  I guess we have a registry
of
> CORS-enabled schemes, so it isn't so bad, but I can imagine adding a new
scheme
> in the future that supports credentials and getting in trouble here.

A CORS response cannot have allow credentials if a wildcard is used for the
origin, i.e.
Access-Control-Allow-Credentials: true and
Access-Control-Allow-Origin: *
is an invalid combination (http://www.w3.org/TR/cors/#resource-requests)

This CL's only change is to allow this combination for non-http(s) schemes, so
that protocol handlers in Chromium can use both headers to allow a resource to
be used anywhere without being blocked by the same-origin policy. Think of using
XMLHttpRequest to parse data-URLs or painting data URLs on a canvas.

[robwu, 2014-03-17 18:53:45]

abarth: Could you take a look?

[abarth-chromium, 2014-03-17 20:11:05]

lgtm

ok

[abarth-chromium, 2014-03-17 20:11:11]

The CQ bit was checked by abarth@chromium.org

[commit-bot: I haz the power, 2014-03-17 20:11:13]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rob@robwu.nl/192573011/20001

[commit-bot: I haz the power, 2014-03-17 20:38:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-17 20:38:25]

Try jobs failed on following builders:
  tryserver.blink on linux_blink_rel

[robwu, 2014-03-17 20:40:17]

The CQ bit was checked by rob@robwu.nl

[commit-bot: I haz the power, 2014-03-17 20:40:22]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rob@robwu.nl/192573011/20001

[commit-bot: I haz the power, 2014-03-17 21:05:32]

Change committed as 169391