-
-
Notifications
You must be signed in to change notification settings - Fork 63
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
Fixes #48 #49
Fixes #48 #49
Conversation
3dd062a
to
8c58031
Compare
- Added support for configured canned ACL on S3 put call. - Added to readme with new parameter. - Added to s3 gitlab example.
8c58031
to
3ee666c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code looks good, just have a question about DO situations
There’s already a call to check if it’s DO so we could leverage that.
The problem with the ACLs is that the response I was getting from the api
was super unhelpful, so I would lean more towards the side of having the
checks against the valid values.
Maybe it could throw an error if the value isn’t valid for either S3 or DO
so it would be easy to see in the logs?
…On Thu, 21 May 2020 at 18:11 Anthony Frehner ***@***.***> wrote:
***@***.**** commented on this pull request.
code looks good, just have a question about DO situations
------------------------------
In src/io-methods/s3.js
<#49 (comment)>
:
> @@ -21,6 +21,17 @@ function parseFilePath(filePath) {
};
}
+const validCannedACLs = [
+ // See: https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html#canned-acl
+ "private", "public-read", "public-read-write", "aws-exec-read", "authenticated-read",
+ "bucket-owner-read", "bucket-owner-full-control", "log-delivery-write"
according to https://developers.digitalocean.com/documentation/spaces/
only private and public-read are available for DO
what should we do in that case? should we be checking to see if they're
using DO and then validate against that set of options?
or should we remove the validation altogether so that we don't have to
ensure we're always up-to-date with 2 external services?
thoughts?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#49 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACEJBWKVIXFKETOKABZD2OTRSVACBANCNFSM4NGVWBGQ>
.
|
yeah I'm good if we just utilize that DO check. |
it could be nice to support any of the S3 PutObject params, instead of just the ACL. See my suggestion at #48 (comment) for what a config file could look like for this. Additionally, another thing to consider is whether to support a different ACL per import-map-deployer location. I'm okay with skipping that for now since it makes things more complicated, but thought I'd bring it up. |
I'll go ahead and make the changes to support any of the s3 parameters. I'll remove the validation that I originally wrote, and just pass along whatever we get from that s3 putObject config. This way we don't need to change code if the values/structure of the putObject changes, and any DO changes would just be in the config. |
156966e
to
0846e23
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me - thanks!
Added support for configured canned ACL on S3 put call.
Added to readme with new parameter.
Added to s3 gitlab example.