Skip to content
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

chore: Add an integration test for SigV4A signing region #1852

Merged
merged 2 commits into from
Dec 27, 2024

Conversation

sichanyoo
Copy link
Contributor

Issue #

2238

Description of changes

  • Adds an integration test that checks that signing region for rules-based SigV4A operations (all SigV4A operations atm use rules-based auth scheme resolution) resolve signing region correctly to * (all SigV4A operations atm just have * for region field for SigV4A auth scheme property in the endpoint)

New/existing dependencies impact assessment, if applicable

Conventional Commits

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

key: SigningPropertyKeys.signingRegion
)
XCTAssertNotNil(resolvedSigningRegion)
XCTAssertEqual(resolvedSigningRegion!, "*") // Assert that the resolved signing region is "*", as expected.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we either (or both) need to 1) re-write this test to use a real endpoint that resolves to 2 different regions and then make requests to both regions (as in the sev2 test code) 2) change this to a unit test since we don't actually need to make a real request to check if the resolvedSigningRegion is *

Copy link
Contributor Author

@sichanyoo sichanyoo Dec 26, 2024

Choose a reason for hiding this comment

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

  1. There's no real endpoint that resolves to 2 different regions atm. Every endpoint for every service that uses SigV4A uses * for signingRegionSet value, including SESv2 that caused the Sev2.
  2. I think using integration test using the actual S3 operation flow is best for testing this, given doing so actually uses the typical auth flow for rules-based auth scheme resolution. Also, since it doesn't make actual network calls, there isn't a downside either for having the test.

Copy link
Contributor Author

@sichanyoo sichanyoo Dec 26, 2024

Choose a reason for hiding this comment

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

After discussion offline we concluded that maybe I could just use SESv2's multiregion (global) endpoint to test it in real-service scenario, but that was called off because all (all two of them) SESv2 API using global endpoints (sendEmail and sendBulkEmail) require involved email verification process that either requires manual verification via clicking a button in the actual email sent to the provided email address, or providing a key pair for a domain name.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

After offline discussion, having the test separated out like this vs. including it into S3 MRAP test is pending tie-breaker from Josh.

@dayaffe dayaffe self-requested a review December 27, 2024 16:51
Copy link
Contributor

@dayaffe dayaffe left a comment

Choose a reason for hiding this comment

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

Discussed on stand, we're fine with having non-network tests in this folder

@sichanyoo sichanyoo merged commit 33bbe2c into main Dec 27, 2024
25 checks passed
@sichanyoo sichanyoo deleted the chore/sigv4a-signing-region-integ-test branch December 27, 2024 17:21
Copy link
Contributor

@jbelkins jbelkins left a comment

Choose a reason for hiding this comment

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

Approved

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.

3 participants