File Storage Read Permissions - Currently World-readable!
I am trying to serve files in storage via getUrl, but I've discovered that those files are world readable, outside convex, on the open internet (e.g. via curl - try it on your side).
How can I control read access to these functions?
Can I set permissions when writing, and if so how?
Is this a job for row-level security/RLS?
Or some other auth mechanism?
What's the correct pattern here?
Is there a workaround?
Many thanks for any and all urgent assistance
10 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
This was discussed recently. Linking that thread here in case it helps: https://discord.com/channels/1019350475847499849/1291524926917836874
Thank you, that is super helpful.
I am still unclear on how to remove access to storage.getUrl (so that this can't be called publically).
Is there a way to override / remove that method?
Can the httpAction achieve this, and if so how?
I'm going to loop in @lee to confirm (as he was in that original thread), but because
ctx.storage.getUrl is a built-in method, removing it is not possible. That said, the only way to use that method is inside a query, mutation, or action handler, as that's the only place where ctx is exposed. The only way for the public to use that method would be if someone got access to your Convex account.
An HTTP action would give you a way to provide controlled access to someone who doesn't have the direct file URL. However, if the file URL was already discovered via other means then the file is already exposed. I could be wrong, but I don't believe there's a way to prevent access to a file via its URL. The whole point of having the URL provide direct access is for convenience when using that file in apps; e.g. an image that needs to be rendered. Locking down the URL would make those basic use cases more difficult.
Could you describe more about your use case?Thanks very much for this helpful explanation.
The use case is: Take a file from convex storage and POST it to my own (AWS) endpoint via its URL.
I could send the binary, but then I have to fetch it from storage first. I could use my own S3 storage instead, but then in convex I have to front it with a new filebrowser..
If I am using convex file storage then any file does appear at <...>.convex.cloud/api/storage/<storageId>. If an external actor just knows storageId, am I right that the file right now has to be accessible? I think you are saying yes! 😦
If that's the case (and sorry if I missed this in the httpActions discussion), can I restrict calls to <...>.convex.cloud/api/storage/<storageId> , and if so how exactly, and where would I configure this?
Thanks so much!
the url is not *.convex.cloud/api/storage/<storageId>. It's *.convex.cloud/api/storage/<uuid> where uuid is a secret, only accessible if you call
ctx.storage.getUrl. So you can lock down access to a file by never calling getUrl -- instead you can use an http action that checks authorization and calls ctx.storage.get@lee OK that's great to know! Just to double confirm my understanding:
The UUID secret is only generated when ctx.storage.getUrl is called. Until then, there is no public URL for the corresponding file, anywhere in existence? So that even if I guessed a UUID I could not access the file publicly?
If that's right then I'll implement your ctx.storage.get route. Thanks!
The uuid does exist beforehand but it's sufficiently random that it's considered unguessable. As my randomized algorithms prof would say, "the chance of it happening is less than the chance of the computer getting hit with two meteors at the same time"
Is there anyway whatsoever to make it cryptographically secure? :\
@JZ I wouldn't worry about it. A lot of internet security works this way--unguessable values. This is as secure as anything. (Encryption keys are also unguessable values if you think about it)