Safari CORS preflight cache OPTIONS method on image uploads (AWS S3 and CORSRules config)

[kdolan1]

Issue:

Safari failing its preflight CORS check on cached images, where the image src is a redirect (Canvas Instructure URL redirect to an AWS S3 bucket).

To duplicate:

1. In Safari (v13.2 with file caching on, Desktop or iOS), Go to site https://cidilabs.instructure.com/courses/3/pages/upload-slash-embed-image-test. I do not control this public page, my apologies if it becomes a broken link. If you have access to a Canvas LMS, you can duplicate this page by uploading an image through the Canvas image upload tool to a module page. Canvas embeds uploaded images as a redirect link to an S3 bucket.
2. Then refresh that page, to initiate a preflight CORS request on the cached image, to see the broken image link.

This is the console error:

FetchEvent.respondWith received an error:
TypeError: Cross-origin redirection to <actual image source> 
denied by Cross-Origin Resource Sharing policy: 
Origin <hosted page containing the image src redirect to image source> 
is not allowed by Access-Control-Allow-Origin.

The original CORS request is fine. It's only the preflight check on cached resource that fails. I'm hoping it's a Safari bug/fixable, because if it's a feature, Chrome & Firefox might follow with the weird behavior. The other possibility is that additional CORS Rules on the server for OPTIONS methods with headers might resolve it for Safari (and future releases of Firefox and Chrome).

Workarounds (non-optimal):

• Always open a private browser when using a page with an embedded CORS redirect image. The issue only happens when the image is cached. [Not a practical solution for users]
• Add a terminating solidus (forward slash) to all cachable resources that are CORS redirect paths. The issue only happens when the redirect path looks like a file not a directory. [I'm torn about this being bad style for image src URL. But, because the image src is really a redirect and not really a file anyway, I think it's not totally bad to show it as a dir.] ** the most practical of the bad workarounds
• Make the image src URL a DIFFERENT host than the page it's embedded in. The issue only seems to happen if the cached image src redirect URL is the same host as the web page. [This is so weird! Maybe, some crazy way Safari caches host page resources.]
• Use FireFox or Chrome when going to a page with a CORS image src redirect. The issue only happens with Safari. [Terrible workaround, cuts out a lot of users]

The Question!

Finally, the QUESTION to the community: Are people addressing this issue by adjusting their CORSrules config on their Canvas server and/or the AWS S3 buckets?

For example, do you have cors rules that include the OPTIONS method, AllowOrigin, and AllowHeaders?

<CORSConfiguration>
 <CORSRule>
  ... PUT, DELETE, POST, etc
  ....
 <CORSRule>
   <AllowedMethod>GET</AllowedMethod>
   <AllowedMethod>OPTIONS</AllowedMethod>
   <AllowedOrigin>*</AllowedOrigin>
   <AllowedHeader>*</AllowedHeader>
 </CORSRule>
</CORSConfiguration>

Related links:

The answer on this link is not working for our issue of Canvas uploaded images: https://community.canvaslms.com/t5/Question-Forum/Uploaded-images-no-longer-function-in-Safari/m-p/3...

I asked the same question about CORS rules for Canvas and S3 here https://github.com/instructure/canvas-lms/issues/1183

An alternative possible help from jQuery library to remove the forced addition of `X-Requested-With: XMLHttpRequest`  header on OPTIONS methods https://github.com/jquery/jquery/issues/4788

[kdolan1]

Regarding the jQuery reference from above, I found that using Safari Inspector, I can add a breakpoint to the jQuery (jQuery v1.7.2) `xhr.send( ( s.hasContent && s.data ) || null );`. Then, reload the page and let the code hang and time out on that line. This prevents the OPTIONS method call from being sent to Canvas. The image loads successfully, with correct headers. The images continue to load successfully, from now on, on every new page refresh.

This implies that the OPTIONS call from this old version of jQuery might be causing problems with Safari image redirect cache.

There are multiple versions of jQuery and other code performing GETs which may contribute to the problem with Safari and Canvas uploaded images.

[kdolan1]

Related to the CORS setup of AWS S3 image bucket for Canvas, can you verify if "Vary: Origin" is added to headers from the S3 bucket?

Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin

"CORS and caching"
If the server sends a response with an Access-Control-Allow-Origin value that is an explicit origin (rather than the "*" wildcard), then the response should also include a Vary response header with the value Origin — to indicate to browsers that server responses can differ based on the value of the Origin request header.

Access-Control-Allow-Origin: https://developer.mozilla.org
Vary: Origin

[kdolan1]

I created a ticket with additional discussion https://github.com/instructure/canvas-lms/pull/1700
The ticket suggests mitigating the issue on the client side while continuing to debug the server side.

[kdolan1]

The following curl checked Access-Control-Allow-Methods for instructure-uploads.s3.amazonaws.com as recommended in AWS S3 ticket referenced below. The OPTIONS method is not listed as one of the accepted methods. Can someone verify if the Safari preflight OPTIONS method is allowed on https://instructure-uploads.s3.amazonaws.com?

Access-Control-Allow-Methods: GET, PUT, POST, OPTIONS <------ missing?

$ curl -H "origin: any" -v "https://instructure-uploads.s3.amazonaws.com"

> GET / HTTP/1.1
> Host: instructure-uploads.s3.amazonaws.com

< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, PUT, POST
< Access-Control-Max-Age: 3000
< Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
< x-amz-bucket-region: us-east-1
< Server: AmazonS3

"By default, CloudFront allows only the GET and HEAD methods, but some web browsers [i.e. Safari] might issue requests for the OPTIONS method."

The CloudFront distribution's cache behavior allows the OPTIONS method for HTTP requests

If you're still seeing errors after you update your CORS policy and forward the appropriate headers, try allowing the OPTIONS HTTP method in your distribution's cache behavior. By default, CloudFront allows only the GET and HEAD methods, but some web browsers might issue requests for the OPTIONS method.

To enable the OPTIONS method on your CloudFront distribution, follow these steps:

1. Open your distribution from the CloudFront console.
2. Choose the Behaviors tab.
3. Choose Create Behavior, or choose an existing behavior, and then choose Edit.
4. For Allowed HTTP Methods, select GET, HEAD, OPTIONS.

https://aws.amazon.com/premiumsupport/knowledge-center/no-access-control-allow-origin-error/

[khdolan]

Possibly related is the the Sept 1st patch to the Canvas LMS service worker specific to Safari 13+ and "file previews" not served by the Instructure file server. The patch was in release Sept 23rd and the Safari 14 CORS image from S3 instructure bucket issue still exists. 

https://github.com/instructure/canvas-lms/commit/eaf502ed22e9d5209c59db03923fbaa8eb54e257

[khdolan]

This patch adding the JWT token (jti) to the Cached image might help Safari (committed 22hours ago!) https://github.com/instructure/canvas-lms/commit/e2e440899574e0fbe8ccbc3d6ca898439bf57852

[philipswids]

This is happening because of the CORS 3 (Cross Origin Resource Sharing) . For every HTTP request to a domain, the browser attaches any HTTP cookies associated with that domain. This is especially useful for authentication, and setting sessions. You are doing an XMLHttpRequest to a different domain than your page is on. So the browser is blocking it as it usually allows a request in the same origin for security reasons. You need to do something different when you want to do a cross-domain request.

JSONP ( JSON with Padding ) is a method commonly used to bypass the cross-domain policies in web browsers. You’re on domain example.com, and you want to make a request to domain example.nett . To do so, you need to cross domain boundaries. JSONP is really a simple trick to overcome the XMLHttpRequest same domain policy. So, instead of using XMLHttpRequest we have to use < script > HTML tags, the ones you usually use to load JavaScript files , in order for JavaScript to get data from another domain.

Localhost

If you need to enable CORS on the server in case of localhost, you need to have the following on request header.

Access-Control-Allow-Origin: http://localhost:9999

Also, this kind of trouble is now partially solved simply by using the following jQuery instruction:

<script>
$.support.cors = true;
</script>

[kdolan1]

HI @philipswild, so why does this only happen with CACHED requests? For example, in Safari, the first time I go to https://cidilabs.instructure.com/courses/3/pages/upload-slash-embed-image-test I see all the images load. Then, when I refresh the page, I get the CORS error.

Why is the XMLHttpRequest same domain policy needed for the cached resource PRE-FLIGHT calls, but not for the original request?

[kdolan1]

... and also, why only Safari, not Firefox or Chrome? I suspect Firefox and Chrome are not doing the PREFLIGHT OPTIONS request, but continue to do the GET. The image response header has no-cache in a lot of the response params, but Safari is ignoring them for some reason.

In another post, someone thought it was the "Content-Type: image/png" that was causing the PREFLIGHT OPTIONS request. 


In the original redirect part of the GET

Redirect Response
302
Pragma: no-cache
Expires: 0
Cache-Control: no-cache, no-store, must-revalidate
...
Vary: Accept-Encoding

There are some posts that Safari might be ignoring the Cache-Control when it sees the Vary: Accept-Encoding.

[kdolan1]

The issue is now resolved in our Canvas instance! Possible related to May 2022 patch https://github.com/instructure/canvas-lms/commit/9977aa411a47e87bac510a0590c8dc5c790868cc