-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding Dynamic bucket & region params to config #169
base: master
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Cool, thanks for the PR! I'd like to understand this a little better... can you show me how'd you use this with code? Do you have if statements inside your |
No worries!
Omitting |
Ok cool , makes sense! I'll probably need a few days before I can get this merged and published. One thing that would help speed things up is if you could add docs to this page: https://next-s3-upload.codingvalue.com/bucket-config |
Yep! |
@ryanto |
Bumping this when possible! |
Bumping this too, my team would benefit from dynamic bucket functionality as we're storing data in both a public and private bucket. Great work here @DhenPadilla. Sorry to spam but a merge would be great @ryanto 🙏 |
@DhenPadilla Thanks for your blessed contribution. We couldn't wait any longer so we created a fork with your changes.
|
Hi @ryanto! Is there anything that's blocking merging this? |
Context
We're using Next-s3-upload to upload to a single bucket currently.
This sufficed for a single use case up until now as we have a strong security requirement to keep the current bucket that we're uploading to be completely READ-restricted to public access (i.e private to anything external to aws). This cannot change.
We want to continue using next-s3-upload for our new use case:
Uploading files to a new bucket which would have public read access.
Currently, next-s3-upload does not allow for dynamically allocating a bucket name and only saves to the
S3_UPLOAD_BUCKET
env var. This is fine for our initial use case, but definitely not moving forward as we may need more than 2 buckets but especially more than 1.Note: Although we're using 1 region, I imagine we (or other users) may use multiple regions now in the future.
I imagine this would help other users of the package, so hopefully this is a solid PR!