-
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
chore: Add an integration test for SigV4A signing region #1852
Conversation
… SigV4A operation.
key: SigningPropertyKeys.signingRegion | ||
) | ||
XCTAssertNotNil(resolvedSigningRegion) | ||
XCTAssertEqual(resolvedSigningRegion!, "*") // Assert that the resolved signing region is "*", as expected. |
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.
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 *
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.
- There's no real endpoint that resolves to 2 different regions atm. Every endpoint for every service that uses SigV4A uses
*
forsigningRegionSet
value, including SESv2 that caused the Sev2. - 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.
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.
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.
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.
After offline discussion, having the test separated out like this vs. including it into S3 MRAP test is pending tie-breaker from Josh.
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.
Discussed on stand, we're fine with having non-network tests in this folder
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.
Approved
Issue #
2238
Description of changes
*
(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.