I have the same problem.

Me too. Any solution?

Hi all, we really shouldn’t have to run a “fix” for this it should “just” work.
The frustrating thing for me is that sometimes it works and sometimes it doesn’t.
I will contact DO today about this. I will let you know what I hear.

I had this issue too!

What ended up solving the issue completely was running a full purge at the space level.

Ensure CDN is enabled, just in case.

Same problem.

Origin: works
CDN: does not work (403 (Forbidden))

Any solution?

Has this issue been solved? Anyone know how, other than purging CDN after each upload?

It seems like private resources (requiring an API token) cannot be fetched from an edge endpoint. This is the response I’ve received from support:

The CDN is independent of Spaces, it’s good for speeding up requests for users who are geographically far away from the origin. However it only houses cached files/objects and serves them to the end-user. This doesn’t work for speeding up normal API operations/requests(via api key/token) for Spaces.

Because they are seperate systems, all Space operations would need to be done at the ‘source’ or origin endpoint. Then once changes are done at origin, your public (and signed URLs) objects will cache to the CDN and be available for end-users/applications to use.

https://developers.digitalocean.com/documentation/spaces/#aws-s3-compatibility

If you made all your objects private in your Space, then when you check the Origin or CDN you would get a 403. In order to access the file via origin it would need to be signed. However there are 2 formats that can be used, 1 will cache to CDN and be available, the other will not and only work through Origin.

An example of signed URLs that WILL NOT cache to the CDN are the QuickShare links in the DigitalOcean UI. They use the following format:
<REGION>.digitaloceanspaces.com/<SPACE>

However if you do want your signed URLs to be cached, use the following format and it WILL be available via CDN:
<SPACE>.<REGION>.digitaloceanspaces.com