Store and serve files with the JavaScript SDK
The everyday flows of `aura.storage`, with the access rules observed against a running stack.
1. Buckets
A bucket groups files and decides whether they are public. Creating and deleting buckets needs a service_role key. Listing them needs a signed-in user or a service_role key; the public key alone gets 403.
A bucket also accepts fileSizeLimit (in bytes) and allowedMimeTypes. An upload that is too large returns 413, and a type that is not allowed returns 400.
2. Upload, download, list, remove
What to expect:
- Uploading an existing path returns
409unless you passupsert: true. - Uploading needs a signed-in user or a
service_rolekey. The public key alone gets403, even for a public bucket. - A path with
..is refused with400. - Paths are shared inside a bucket. If another user already has the path, you get
409. Put each user's files under their own folder, such as${user.id}/….
3. Share a file
Both links were fetched without any key and returned the file. A signed link stops working after expires_in seconds. To let a browser upload without a key, a server mints createSignedUploadUrl(path) (a service_role call).
4. Who can do what
| Action | Public key | Signed-in user | service_role |
|---|---|---|---|
| Read a file in a public bucket | yes | yes | yes |
| Read, list a file in a private bucket | no | its owner only | yes |
| Upload | no | yes | yes |
| Replace or remove a file | no | its owner only | yes |
| List buckets | no | yes | yes |
| Create, delete buckets | no | no | yes |
The owner is the user who uploaded the file. In a real run, a second user could not list, download or remove the first user's file in a private bucket, and could not replace it either.
5. Move and copy, from a server
Image resizing is described in the storage reference.