Configure CORS · Cloudflare R2 docs
Hey all, I've just pushed out a release that finally, FINALLY exposes a UI in the dashboard to configure your bucket's CORS policies! You'll find it on your bucket's Settings page.
I know this has been a pain point for people who just want to use a public bucket without having to deal with the S3 API. We're eager to hear what people think of it, and if you have ideas for changes/improvements. I'll create a thread for this so we don't lose your suggestions to time
Also accompanying this UI is a new docs page about CORS where suggestions are welcome too: https://developers.cloudflare.com/r2/learning/cors
Configure CORS · Cloudflare R2 docs
Cross-Origin Resource Sharing (CORS) is a standardized method that prevents domain X from accessing the resources of domain Y. It does so by using …
18 Replies
Post your thoughts here!
cc @arunc | Workers @erinthames
This union allows “OPTIONS” - which is not a valid option
Conversely, it doesn’t allow “HEAD” when it should have
These two links go to https://developers.cloudflare.com/r2/data-access/public-buckets/#connect-your-bucket-to-a-custom-domain when I’d assume they should actually be going to https://developers.cloudflare.com/r2/learning/cors
The CORSRule shape should also include an optional “id” field - which would be cool to show here if present - but I’m not really aware of many people using it so likely not a high priority.
Deleting a CORS rule has no confirmation - which is less of a bug and more of a feature request. Of course deleting it incidentally can cause an outage, and it’s right below the edit option.
I've submitted those points through the feedback form - I assume that goes somewhere where it's easier to collate and reference haha
Oh,
AllowedMethods shouldn't accept * either.Thanks Kian! I’ll take care of the bugs, and Arun/Erin can probably chime in with their thoughts about confirmation on delete
Funnily enough, S3's own CORS editor in the dashboard doesn't accept the
Id field either but everything else does
Good old S3What does the ID even do? I don’t think we do anything with it TBH
Literally just an optional identifier
Has no impact on CORS, just for organisation I suppose
Currently the
?cors XML endpoint supports it - and I guess it'd disappear if you then save a CORS rule in the dashboard without it. It's missing from some S3 docs pages, present on others, not supported by their own CORS UI - but is then supported it in the SDK example next to it.
In true AWS fashion
I guess people might use it to link tickets/change requests to a CORSRule or explain some more detail - I think you get 255 characters so it's a decent length to provide context to a rule - but I don't know anyone who actually uses it
On the note of this: when I say it shouldn't, that's just because S3 don't and neither does R2 currently (the save will fail) - as opposed to telling you what not to implement hahaI may or may not have forgotten to cross check autocompletion items against R2 and instead just committed the values I was playing around with 😬
Access-Control-Allowed-Methods: * is valid though, maybe we should accept itMakes sense - but I guess it's less of a wildcard, and more-so that it has special meaning.
i.e you might think
* means everything so I can do a signed PUT request - but that won't work, since * dictates requests without credentials
Why they picked a wildcard to in-fact not be a wildcard, is weird - but I guess they don't have many options when every value should be a method name
I guess what I'm trying to say is that people might think it means 'allow all methods', when it actually means how Access-Control-Allowed-Methods treats * as a special case rather than 'allow all'
I suppose the right documentation/tooltips can stop thatNo yeah I see what you mean
Eh who reads docs that thoroughly
write docs if only just to be able to reply to people with a link rather than type it all out for the 9th timeUnknown User•3y ago
Message Not Public
Sign In & Join Server To View
