access-control-allow-origin header missing from objects even after adding CORS settings in Digitaloc-CodePudding

I have added added CORS configurations in the DigitalOcean Spaces UI like this:

Still I don't get access-control-allow-origin header on the object request from my browser.

When the objects are uploaded from my backend, "public-read" is set as ACL.

I am expecting, when the object (image in my case) request is made from my web app in the browser, it's response headers should have access-control-allow-origin: http://my.machine.localhost.

This is a hard requirement by HTML canvas toDataURL() when the canvas component has images from non-origin sources.

CodePudding user response：

First the localhost problem

DO (DigitalOCean) doesn't let you configure localhost in the CORS origin field. For this, you can update your /etc/hosts to give your localhost an acceptable name. I have

127.0.0.1        my.machine.localhost

This way it's easy to configure in the DO spaces CORS settings and hitting my.machine.localhost in your browser should open your app running on localhost (I run my app on port 80).

Second, the CORS headers

Disable CDN until you fix the problem or you have to purge cache multiple times. Use curl or httpie or something similar to test as browsers tend to cache objects.

I am assuming objects are uploaded with public-read ACL.

Now check the request and response headers with curl or httpie.

$ http -v https://***.***.digitaloceanspaces.com/static/images/logo.png

Here's the tricky part - even though you have your CORS configured, the response will not have access-control-allow-origin header. To get it working, you need to set the Origin header in your request which needs to match with at-least one of the configured origins in DO Spaces UI for your bucket.

$ http -v https://***.***.digitaloceanspaces.com/static/images/logo.png "Origin:http://my.machine.localhost"

This will return access-control-allow-origin and access-control-allow-methods as per your configuration.

DO spaces implements the same API as AWS S3. So it's better to look for S3 documents when stuck. I found this in the AWS S3 CORS documents https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors-troubleshooting.html

If the header is missing, Amazon S3 doesn't treat the request as a cross-origin request, and doesn't send CORS response headers in the response.

There are many tutorials online which recommends using s3cmd and setting CORS with wildcards * - think twice before doing these as it's very insecure.