Friday, July 27, 2018

CORS policy on cached Image

By Hường Hana 2:00 AM , , , , Leave a Comment

In chrome 22 & safari 6.

Loading images from s3 for usage in a canvas (with extraction as a primary intent) using a CORS enabled S3 bucket, with the following code:

<!-- In the html --> <img src="http://s3....../bob.jpg" />   // In the javascript, executed after the dom is rendered this.img = new Image(); this.img.crossOrigin = 'anonymous'; this.img.src = "http://s3....../bob.jpg";

I have observed the following:

  1. Disable caches
  2. Everything works fine, both images load

Then trying it with caches enabled:

  1. Enable caches
  2. DOM image loads, canvas image creates a dom security exception

If I modify the javascript portion of the code to append a query string, like so:

this.img = new Image(); this.img.crossOrigin = 'anonymous'; this.img.src = "http://s3....../bob.jpg?_";

Everything works, even with caching enabled fully. I got on to the caching being a problem by using an http proxy and observing that in the failure case, the image isn't actually being requested from the server.

The conclusion I'm forced to draw is that the image cache is saving the original request headers, which are then being used for the subsequent CORS enabled request - and the security exception is being generated due to violation of the same origin policy.

Is this intended behavior?

Edit: Works in firefox.

Edit2: Cors policy on s3 bucket

<?xml version="1.0" encoding="UTF-8"?> <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">     <CORSRule>         <AllowedOrigin>*</AllowedOrigin>         <AllowedMethod>GET</AllowedMethod>     </CORSRule> </CORSConfiguration>

I'm using wide open because I'm just testing from my local box right now. This isn't in production yet.

Edit3: Updated cors policy to specify an origin

<?xml version="1.0" encoding="UTF-8"?> <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">     <CORSRule>         <AllowedOrigin>http://localhost:5000</AllowedOrigin>         <AllowedMethod>GET</AllowedMethod>     </CORSRule> </CORSConfiguration>

Verified outgoing headers:

Origin  http://localhost:5000 Accept  */* Referer http://localhost:5000/builder Accept-Encoding gzip,deflate,sdch Accept-Language en-US,en;q=0.8 Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.3

Incoming headers:

Access-Control-Allow-Origin http://localhost:5000 Access-Control-Allow-Methods    GET Access-Control-Allow-Credentials    true

Still fails in chrome if I don't bust the cache when loading into the canvas.

Edit 4:

Just noticed this in the failure case.

Outgoing headers:

GET /373c88b12c7ba7c513081c333d914e8cbd2cf318b713d5fb993ec1e7 HTTP/1.1 Host    amir.s3.amazonaws.com User-Agent  Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.91 Safari/537.4 Accept  */* Referer http://localhost:5000/builder Accept-Encoding gzip,deflate,sdch Accept-Language en-US,en;q=0.8 Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.3 If-None-Match   "99c958e2196c60aa8db385b4be562a92" If-Modified-Since   Sat, 29 Sep 2012 13:53:34 GMT

Incoming headers:

HTTP/1.1 304 Not Modified x-amz-id-2  3bzllzox/vZPGSn45Y21/vh1Gm/GiCEoIWdDxbhlfXAD7kWIhMKqiSEVG/Q5HqQi x-amz-request-id    48DBC4559B5B840D Date    Sat, 29 Sep 2012 13:55:21 GMT Last-Modified   Sat, 29 Sep 2012 13:53:34 GMT ETag    "99c958e2196c60aa8db385b4be562a92" Server  AmazonS3

I think this is the first request, triggered by the dom. I don't know that it isn't the javascript request though.

3 Answers

Answers 1

The problem is that the image is cached from a former request, without the required CORS headers.Thus, when you ask for it again, for the canvas, with the 'crossorigin' specified, the browser uses the cached version, doesn't see the necessary headers, and raises a CORS error. When you add the '?_' to the url, the browser ignores the cache, as this is another URL. Take a look at this thread: https://bugs.chromium.org/p/chromium/issues/detail?id=409090

Firefox and other browsers do no have that problem.

Answers 2

What CORS settings are you applying? This post suggests that wildcards in AllowedOrigin are parsed (rather then being sent verbatim, this appears to be undocumented behaviour); and the Access-Control-Allow-Origin header value is then cached for subsequent requests, causing issues similar to what you're reporting.

Answers 3

I had a very similar problem and solved it by adding the following header to the response from the server.

'Vary': 'Origin'

After adding the header all my requests got cached.

If You Enjoyed This, Take 5 Seconds To Share It

0 comments:

Post a Comment