Allow anonymous access on the S3 endpoint #263
Labels
No Label
AdminAPI
Bug
Check AWS
CI
Correctness
Critical
Documentation
Ideas
Improvement
Low priority
Newcomer
Performance
S3 Compatibility
Testing
Usability
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#263
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This issue tracks wether we want to allow anonymous access on the S3 endpoint and how (currently we allow anonymous access only on the website endpoint that we can use as a "fake" CDN). This is the place to reference which applications are using it, and wether we have a workaround for them.
Currently, the following apps are known to use anonymous access on the S3 API:
Other apps we suspect may need this workaround:
This would be a great feature. I regularly use minio with the following use case: I upload a file to a bucket, and a link to this file is then shared (with the https://s3.domain.tld/bucket/file.ext URL).
It would be great to be able to transition to garage, but I can't change the shared links.
Thus having a feature like this would help, even better with a file granularity on what is read-only and what is not accessible.
I know it would be possible to setup a workaround by using the web port, but I would like to avoid having to change the subdomain.
So yeah, that's my use case for anonymous access to buckets! :-)
Any update on this regarding a possible inclusion in the roadmap?
Sorry, it's quite low priority and I don't have time to dedicate to this currently, so it's not on any roadmap. Feel free to work on this yourself if you're interested :)
Outline
use this feature ;)