So, after some thought and thorough
So, after some thought and thorough reading, I think the reason the documentation was misleading is this part here. It implies that the example code blocks are meant for:
1. Presigning, using a worker, or something else (it mentions a dedicated worker or other app just for signing...)
2. Using the presigned URL, from within a worker, one that has the R2 bucket binding, which will make it automatically authenticate against R2, and is why they omit the configs
This to me seems rather useless... you run into the same limits (request size, etc) as if you had just used the R2 binding directly, and gain none of the benefits typically associated with (and mentioned at the top of the article) for presigning. But I digress.
It seems like every person who has run into this here on Discord had the same assumption I did - presigning using this example to then use the presigned url outside a worker, which is not what the example, nor the special notes about authentication, are for at all.
3 Replies
Hey, the Presigned URL docs do mention authentication and has a code block that shows
accessKeyId and secretAccessKey. Using Worker with bindings is mentioned as an alternative. It would help if you can share the exact part of the docs that was confusing.
Moreover, the examples are provided as a starting place. Their purpose is to show how do something in the most basic fashion.Yeah, I did notice that after reading through the entire documentation and those linked pages. The confusing part is the flow of the documentation, not necessarily its contents. It went something like this:
1. Search for presigning of urls using R2, with the purpose being to let users upload from a browser, directly to R2
2. Find this page at the top of any kind of search result
3. Find a section dedicated to Workers, think "oh yeah, I'm using that - this is for me" (see image)
4. Become very confused and go down a rabbit hole of various issues, since this section, was, in fact, not for me
Another tidbit is that example here uses
aws4fetch in the workers example, and none of the other examples use this client. The assumption then is that this is the only client that works with Workers, because:
- This is generally the case with fetch/web-compatible libraries compared to nodejs/other js ones
- The word "alternative" in the section title carries weight with it, signals that other approaches do not work when using Workers
I think thats the full extent of the confusion. Some of it is pedantic but may still be valuable to take a look over and see if you can clarify. I also think an example section dedicated to this use case (presign R2 url from worker, upload to it with cURL or something) could be really helpful, since it's not the first time someone has gone through the same process & issues as me here on Discord.
Thank you for the feedback. This is really helpful. What I have done for now is created an issue on GitHub to make sure this doesn't get lost. In the coming weeks, I'll work on this and try to make it better. Here's the GitHub issue link: https://github.com/cloudflare/cloudflare-docs/issues/19190
GitHub
[R2] Clarify Presigned URL docs · Issue #19190 · cloudflare/cloudfl...
Existing documentation URL(s) https://developers.cloudflare.com/r2/api/s3/presigned-urls/ What changes are you suggesting? Developers have reported issues understanding how to use Presigned URL for...