Storage security and limits
Storage runs inside one tenant site and one app at a time. Access is decided in two steps: platform login and roles first, then a per-bucket policy for each file operation.
Who can do what
Bucket administration (create, change settings, delete a bucket) requires an organization owner or admin, or another cloud user with access to the site.
Object work (upload, download, list, copy, move, delete) always requires a signed-in user, except that anyone may download a file marked public.
Policy checks run for every sensitive object action. Each bucket has its own policy. Changing who can upload or delete means updating that bucket’s policy, not changing application code.
Default policies by bucket type
When you create a bucket, you choose a category. That choice sets the starting policy:
| Category | Typical default |
|---|---|
| Assets | Signed-in users can read. Upload, update, and delete need extra policy rules. |
| Attachments | Signed-in users can read, upload, and update. Delete needs an extra policy rule. |
Public files can be read without login. Editing a SharePoint-backed Office file always requires login and a passing policy check, even when the file is public.
Batch upload and batch delete check each file separately. Allowed items succeed; denied items appear in the response failed list instead of failing the whole request.
Listing and browse
Listing objects requires login. If a bucket is public but the caller cannot read the whole bucket, list results only include files that are effectively public.
The folder-style browse endpoint always requires login, including for public buckets.
Tenancy
Buckets and objects never cross tenants. Everything stays in the site that owns the app. Anonymous users cannot list bucket contents—only fetch individual public files when you expose them.
Destructive actions
Deleting a bucket removes every object in it and its access policy. Cloud access is required. There is no undo in the API.
Deleting one file or a batch removes the record and the copy in S3 or SharePoint. Batch delete accepts up to 100 paths per call.
Data handling
- File bytes live in S3 or SharePoint, not in the database.
- Object metadata is small (up to about 2 KB) and stored as plain text—do not put secrets in metadata.
- Download links in API responses still require permission unless the object is public.
- SharePoint view and edit links are per user; do not share them between people.
Numeric limits
Upload size, batch sizes, metadata caps, and optional bucket quotas are listed on Configured limits. Quota usage is recalculated periodically, so crossing a quota flags the bucket but doesn't block the next upload.
Report a problem
If a private file is readable without signing in, a user sees another app's bucket, or a delete succeeds when policy should deny it, contact TaruviBase support. Don't post reproduction steps in public channels.