Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Implement Bucket ACL operations in S3 provider #6875

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

Merged
merged 1 commit into from
Sep 26, 2022
Merged

Implement Bucket ACL operations in S3 provider #6875

merged 1 commit into from
Sep 26, 2022

Conversation

bentsku
Copy link
Contributor

@bentsku bentsku commented Sep 14, 2022

No integration tests were really checking ACLs, so this one is not reducing tests failure as much.

  • Implement Bucket ACL operations and validation in provider.
  • ACL enforcement is not part of it, as it's not currently done in the current provider.

@bentsku bentsku temporarily deployed to localstack-ext-tests September 14, 2022 20:47 Inactive
@github-actions
Copy link

github-actions bot commented Sep 14, 2022

LocalStack integration with Pro

       3 files  ±0         3 suites  ±0   1h 11m 38s ⏱️ - 9m 12s
1 309 tests +2  1 195 ✔️ ±0  114 💤 +2  0 ±0 
1 821 runs  +2  1 563 ✔️ ±0  258 💤 +2  0 ±0 

Results for commit 3a18121. ± Comparison against base commit cf8a254.

♻️ This comment has been updated with latest results.

@bentsku bentsku temporarily deployed to localstack-ext-tests September 20, 2022 13:21 Inactive
@bentsku bentsku temporarily deployed to localstack-ext-tests September 20, 2022 13:30 Inactive
@bentsku bentsku temporarily deployed to localstack-ext-tests September 21, 2022 13:20 Inactive
@bentsku bentsku temporarily deployed to localstack-ext-tests September 23, 2022 09:21 Inactive
@bentsku bentsku changed the title WIP: implement Bucket ACL operations in S3 provider Implement Bucket ACL operations in S3 provider Sep 23, 2022
@bentsku bentsku marked this pull request as ready for review September 23, 2022 09:24
@bentsku bentsku temporarily deployed to localstack-ext-tests September 23, 2022 10:01 Inactive
Copy link
Member

@thrau thrau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! if you want we can modify ASF to make it easier to construct exception that have attributes, let me know.

Comment on lines +455 to +458
ex = InvalidArgument(message)
ex.ArgumentName = name
ex.ArgumentValue = value
return ex
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it help if we made it easier to set the exception attributes, so you can raise

raise InvalidArgument(message, ArgumentName=name, ArgumentValue=value)

?

there are two ways that we can do that. either we change the scaffold to create the constructors of exceptions accordingly, or we extend the ServiceException constructor to accept kwargs, to something like:

    def __init__(self, *args, **kwargs):
        super(ServiceException, self).__init__(*args)

        if len(args) >= 1:
            self.message = args[0]
        else:
            self.message = ""
         
        for k,v in kwargs.items():
            setattr(self, k) = v

the second option is simpler and also easier to implement, however it makes it harder to subclass or customize the constructor. the first approach would maybe be cleaner but also a bit more effort.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right! I think right now, it's not exactly needed, as it concerns only S3. I'm thinking about maybe creating a new file exceptions.py for s3, with the helpers to create the necessary exceptions.
I have some kind of a weird case here with presigned URLs: some exceptions have a lot of members (up to 7 I think), but some fields are not returned nor created, depending on the kind of exceptions. So attaching conditionally the members is quite practical.
If I document it better, maybe it can just be know for s3 that you need to create the exceptions with the helper methods. And I like being able to add some logic while creating the exceptions, like the Bytes version of the field.
Presigned URL exception example:

def create_signature_does_not_match_sig_v2(
request_signature: str, string_to_sign: str
) -> SignatureDoesNotMatch:
ex = SignatureDoesNotMatch(
"The request signature we calculated does not match the signature you provided. Check your key and signing method."
)
ex.AWSAccessKeyId = TEST_AWS_ACCESS_KEY_ID
ex.HostId = FAKE_HOST_ID
ex.SignatureProvided = request_signature
ex.StringToSign = string_to_sign
ex.StringToSignBytes = to_bytes(string_to_sign).hex(sep=" ", bytes_per_sep=2).upper()
return ex
def create_signature_does_not_match_sig_v4(
not_valid_sig_v4: NotValidSigV4Signature,
) -> SignatureDoesNotMatch:
ex = create_signature_does_not_match_sig_v2(
request_signature=not_valid_sig_v4["signature_provided"],
string_to_sign=not_valid_sig_v4["string_to_sign"],
)
ex.CanonicalRequest = not_valid_sig_v4["canonical_request"]
ex.CanonicalRequestBytes = to_bytes(ex.CanonicalRequest).hex(sep=" ", bytes_per_sep=2).upper()
return ex

But I still like your proposal, it's pretty clean. But not sure it's worth the trouble.

@bentsku bentsku merged commit 79a0434 into master Sep 26, 2022
@bentsku bentsku deleted the s3-asf-acl branch September 26, 2022 13:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants