get around cross-origin resource sharing on Amazon Aws

问题

I am creating a Virtual reality 360-degree video website using the krpano html5 player.

This was going great until testing on safari and I realised it didn't work. The reason for this is because safari does not support CORS (cross-origin resource sharing) for videos going through WebGL.

To clarify, if my videos where on the same server with my application files it would work, but because I have my files hosted on Amazon s3 , they are CORS. Now I'm unsure what to do because I have built my application on digital ocean which connects to my amazon s3 bucket, but I cannot afford to up my droplet just to get the storage I need(which is around 100GB to start and will increase in the future to Terrabytes and my video collection gets bigger).

So does anyone know a way I can get around this to make it seem like the video is not coming from a different origin or alternatively anything I can do to get past this obstacle?

Is there any way that I could set up amazon s3 and amazon EC2 so that they dont see each other as cross-origin resource sharing?

EDIT:

I load my videos like this:

<script>

function showVideo(){
    embedpano({

        swf:"/krpano/krpano.swf",

        xml:"/krpano/videopano.xml",

        target:"pano",

        html5:"only",

    });

}

</script>

This then calls my xml file which calls the video file:

<krpano>
    <!-- add the video sources and play the video -->
    <action name="add_video_sources">
        videointerface_addsource(‘medium', 'https://s3-eu-west-1.amazonaws.com/myamazonbucket/Shoots/2016/06/the-first-video/videos/high.mp4|https://s3-eu-west-1.amazonaws.com/myama…ideos/high.webm');
        videointerface_play(‘medium');
    </action>
</krpano>

I don't know exactly how krpano core works, I assume it the javascript gets the URLs from the XML file and then makes a request to pull them in.

回答1:

@datasage mentions in comments that CloudFront is a common solution. I don't know if this is what he was thinking of but it certainly will work.

I described using this solution to solve a different problem, in detail, on Server Fault. In that case, the question was about integrating the main site and "/blog/*" from a different server under a single domain name, making a unified web site.

This is exactly the same thing you need, for a different reason.

Create a CloudFront distribution, setting the alternate domain name to your site's name.

Create two (or more) origin servers pointing to your dynamic and static content origin servers.

Use one of them as default, initially handling all possible path patterns (*, the default cache behavior) and then carve out appropriate paths to point to the other origin (e.g. /asset/* might point to the bucket, while the default behavior points to the application itself).

In this case, CloudFront is being used other than for its primary purpose as a CDN and instead, we're leveraging a secondary purpose, using it as a reverse proxy that can selectively route requests to multiple back-ends, based on the path of the request, without the browser being aware that there are in fact multiple origins, because everything sits behind the single hostname that points to CloudFront (which, obviously, you'll need to point to CloudFront in DNS.)

The caching features can be disabled if you don't yet want/need/fully-understand them, particularly on requests to the application itself, where disabling caching is easily done by selecting the option to forward all request headers to the origin, in any cache behavior that sends requests to the application itself. For your objects in S3, be sure you've set appropriate Cache-Control headers on the objects when you uploaded them, or you can add them after uploading, using the S3 console.

Side bonus, using CloudFront allows you to easily enable SSL for the entire site, with a free SSL certificate from Amazon Certificate Manager (ACM). The certificate needs to be created in the us-east-1 region of ACM, regardless of where your bucket is, because that is the region CloudFront uses when fetching the cert from ACM. This is a provisioning role only, and has no performance implications if your bucket is in another region.

回答2:

You need to allow your host in CORS Configuration of your AWS-S3 bucket .

Refer to Add CORS Configuration in Editing Bucket Permissions.

Hence after that, every request you make to the S3 bucket files, will have CORS headers set.

In case you need to serve the content via AWS-CDN CloudFront then follow these steps, ignore if you server content directly via S3 :

1. Go to AWS CloudFront Console.
2. Select your CloudFront Distribution.
3. Go to Behaviors Tab.
4. Create a Behavior(for the files which needs to be served with CORS Header).
5. Enter Path Pattern, Select Protocol & Methods.
6. Select All in Forward Headers option.
7. Save the behavior.
8. If needed, Invalidate the CloudFront Edge Caches by running an Invalidation request for the Files you just allowed for CORS.

来源：https://stackoverflow.com/questions/38187127/get-around-cross-origin-resource-sharing-on-amazon-aws