My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 82042: CORS for canvas (drawImage and texImage2D)
6 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  abarth@chromium.org
Closed:  Jun 2011
Cc:  kbr@chromium.org, jap...@chromium.org

Restricted
  • Only users with EditIssue permission may comment.


Sign in to add a comment
 
Reported by jdarpin...@gmail.com, May 9, 2011
Cross-Origin Resource Sharing should allow drawing cross-domain image/video elements into canvas 2D and WebGL contexts without tainting the origin-clean state of the canvas (so toDataURL/getImageData/readPixels still work).

http://www.w3.org/TR/cors/#use-cases
Jun 24, 2011
#1 fredsa@google.com
I'm seeing this with: 13.0.782.32 (Official Build 89955) beta

Sending this HTTP header when returning the image resource from the other domain does not help:
  Access-Control-Allow-Origin: *

I still get a:
  Uncaught Error: SECURITY_ERR: DOM Exception 18

Jun 24, 2011
#2 kbr@chromium.org
This was implemented by abarth and japhet, culminating in https://bugs.webkit.org/show_bug.cgi?id=61015 and is in Chrome M13.

@fredsa, I'll update the other bug with more information -- your test case appears to be passing now.

Status: Fixed
Owner: abarth@chromium.org
Cc: kbr@chromium.org jap...@chromium.org
Labels: -Area-Undefined Area-WebKit Mstone-13
Jul 7, 2011
#3 kan...@gmail.com
I'm on Chrome 14 (14.0.803.0 dev) and still get "Error: SECURITY_ERR: DOM Exception 18" when trying toDataURL on canvas that has cross-origin image (but with "access-control-allow-origin: *") drawn.
Jul 7, 2011
#4 kbr@chromium.org
Please provide a test case. This functionality is known to be working, though there are bugs -- for example, if the image was cached without the CORS state, then you'll need to clear the cache to get it to be picked up. Also, it is necessary to set the crossOrigin attribute of the image element to "" or "anonymous" in order for any CORS headers in the response to be obeyed.

Jul 7, 2011
#5 kan...@gmail.com
I wasn't aware of "crossOrigin" property. Is this non-standard? How come mere presence of header doesn't leave origin-clean set to true?
Jul 7, 2011
#6 abarth@chromium.org
The crossOrigin attribute is part of HTML5.

It's necessary because it changes how the request is sent (e.g., without cookies), which makes the whole thing secure.
Jul 7, 2011
#7 kbr@chromium.org
See http://blog.chromium.org/2011/07/using-cross-domain-images-in-webgl-and.html for some more background and information on the newly introduced and implemented crossOrigin attribute.

Jul 7, 2011
#8 kan...@gmail.com
I searched current version of WHATWG, as well as CORS draft but don't see any mention of "crossOrigin" property. Could you point me to where it's spec'd?

I also don't see why it's necessary to set "crossOrigin" in order for canvas to not lose its "origin-clean" flag? Isn't the point of SOP restriction in `toDataURL` to prevent data leaking from remote resource? Why would it matter if image request was sent with cookies or not? If remote resource explicitly permits data to be read from other origins, why should those origins be setting property on images?
Jul 7, 2011
#10 abarth@chromium.org
It's a design property of CORS that sending Access-Control-Allow-Origin: * doesn't expose cookie-protected content.  The working group made that decision based on implementation experience with Flash's crossdomain.xml file, which is a security disaster because it has an "allow *" that exposes cookie protected content.

In any case, this isn't the proper forum to discuss these issues.  The proper forum is the W3C.
Oct 27, 2011
#11 postfil...@gmail.com
Did something change with CORS handling for WebGL (texImage2D)? 

New Chrome Canary 17.0.919.0 started to throw CORS exceptions for images coming from the same origin when requested with image.crossOrigin = '';

Is this intended behavior or a bug?

WebGL specs are somehow unclear on this - what should happen when you ask for CORS resource with the same origin and server then doesn't grant permission. 

Oct 27, 2011
#12 kbr@chromium.org
This was a recent change in WebKit implemented by abarth to bring WebKit's CORS implementation into compliance. See http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#potentially-cors-enabled-fetch .

If an anonymous CORS-enabled fetch is made and the server doesn't grant permission, the fetched data is dropped and an error is reported.

This has been Firefox's behavior; WebKit's previous behavior was incorrect.

Oct 27, 2011
#13 postfil...@gmail.com
Thanks.

At least on Windows 7, Firefox behaves differently. Both current stable Firefox 7.0.1 and latest Firefox nightly 10.0a1 (2011-10-27) do work ok with examples that throw CORS exception on latest Chrome Canary 17.0.919.0.

Just to clarify - the use case that started to behave differently recently is when you ask for anonymous CORS (by setting image.crossOrigin='') even when it would not be needed (because the script and image share the same origin).




Oct 27, 2011
#14 abarth@chromium.org
Can you file a new bugs with this information in bugs.webkit.org and cc me (with my @webkit.org email address).  I'll follow up and make sure we've got this correct.
Oct 27, 2011
#15 postfil...@gmail.com
Thanks for looking into this. I filed WebKit issue here:

https://bugs.webkit.org/show_bug.cgi?id=71053
Oct 27, 2011
#16 abarth@chromium.org
Thanks.
Nov 3, 2011
#17 abarth@chromium.org
I've uploaded a patch to the WebKit issue.
Oct 13, 2012
#18 bugdro...@chromium.org
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Labels: Restrict-AddIssueComment-Commit
Mar 10, 2013
#19 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Area-WebKit -Mstone-13 Cr-Content M-13
Mar 13, 2013
#20 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Apr 5, 2013
#21 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Cr-Content Cr-Blink
Sign in to add a comment

Powered by Google Project Hosting