-
Notifications
You must be signed in to change notification settings - Fork 853
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
Add tests to assert signer and endpoint auth-scheme behaviors #4651
base: master
Are you sure you want to change the base?
Add tests to assert signer and endpoint auth-scheme behaviors #4651
Conversation
try { | ||
client.streamingInputOperation(r -> {}, RequestBody.fromString("test")); | ||
} catch (Exception 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.
Can we switch instead to use an interceptor and assert that the exception is the expected one?, See for instance the setup in the tests here. Rationale, this ensures that the exception thrown is exactly what we expect instead of something else failing in the middle.
For instance, the assertion will be instead
assertThatThrownBy(() -> client.streamingInputOperation(r -> { }, RequestBody.fromString("test")))
.hasMessageContaining("boom!");
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.
Point taken. We don't need the interceptor, we can just use the mocked signer to do that.
argThat(attrs -> | ||
"us-west-2".equals(attrs.getAttribute(AwsSignerExecutionAttribute.SIGNING_REGION).id()) && | ||
"query-test-v4".equals(attrs.getAttribute(AwsSignerExecutionAttribute.SERVICE_SIGNING_NAME)) && | ||
!attrs.getAttribute(AwsSignerExecutionAttribute.SIGNER_DOUBLE_URL_ENCODE)) |
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.
Nit, I think that being explicit with the expected value makes this test easier to read, e.g.,
Boolean.FALSE.equals(attrs.getAttribute(AwsSignerExecutionAttribute.SIGNER_DOUBLE_URL_ENCODE)))
} | ||
|
||
private static ProtocolQueryAuthSchemeProvider v4AuthSchemeProviderOverride() { | ||
return __ -> { |
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.
Nit, can we use a letter here instead? (e.g., x -> {...}
)
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.
It's unused, and this is a fairly common when the variable is unused.
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.
Not in Java, and I can't find any other test in the project using it (didn't search thoroughly), but up to the team.
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.
(c.f., the commonly used pattern on some other languages _
is not even possible in Java since a single underscore is reserved).
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.
Yep, hence the usage of two underscores. Changed to 'x'.
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.
You forgot this one and the other below.
.authSchemeProvider(v4AuthSchemeProviderOverride()) | ||
.credentialsProvider(StaticCredentialsProvider.create(AwsBasicCredentials.create("akid", "skid"))) | ||
.endpointProvider(v4EndpointProviderOverride()) | ||
.region(Region.US_WEST_2) |
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.
Nit, let's use here another region to make it clear that the override is working as expected
.region(Region.US_WEST_2) | |
.region(Region.AP_SOUTH_1) |
public Signer mockSigner = mock(Signer.class); | ||
|
||
@Test | ||
public void test_whenV4EndpointAuthSchemeWithSignerOverride_thenEndpointParamsShouldPropagateToSigner() { |
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.
Nit, SonarCloud have complained before about the test methods being public
public void test_whenV4EndpointAuthSchemeWithSignerOverride_thenEndpointParamsShouldPropagateToSigner() { | |
void test_whenV4EndpointAuthSchemeWithSignerOverride_thenEndpointParamsShouldPropagateToSigner() { |
|
||
@BeforeAll | ||
static void setup() { | ||
when(mockSigner.sign(any(), any())).thenThrow(new RuntimeException("boom!")); |
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.
The idea behind using the interceptor instead is two folded, it's the pattern used by the Java team and I been asked before to use it, and, the exceptions is thrown before transmission, IOW, you also validate that everything else in the execution pipeline runs as expected and it's not throwing somewhere else due to the setup you have here.
.authSchemeProvider(v4AuthSchemeProviderOverride()) | ||
.credentialsProvider(StaticCredentialsProvider.create(AwsBasicCredentials.create("akid", "skid"))) | ||
.endpointProvider(v4EndpointProviderOverride()) | ||
.region(Region.US_WEST_1) |
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.
The idea behind the ask to change the region here was that you can validate that the override takes place, given that the region here is the same as the override we cannot know whether is it coming from the client builder or from the override.
} | ||
|
||
private static ProtocolQueryAuthSchemeProvider v4AuthSchemeProviderOverride() { | ||
return __ -> { |
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.
You forgot this one and the other below.
405fcf1
to
5cf2ed1
Compare
Kudos, SonarCloud Quality Gate passed! |
// Use auth scheme provider that the user specified at the request level with | ||
// preference over that which is configured on the client. | ||
AuthSchemeProvider authSchemeProvider = | ||
executionAttributes.getOptionalAttribute(SdkInternalExecutionAttribute.AUTH_SCHEME_RESOLVER) |
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.
Directly setting AUTH_SCHEME_RESOLVER into ExecutionAttributes is not how users would specify request level override for it. These attributes are SdkInternalExecutionAttributes (and SdkProtectedApi) which customers are not supposed to use directly. Even if they can set ExecutionAttributes in RequestOverrideConfiguration. To resolve this TODO we need to support a first class setter somewhere in RequestOverrideConfiguration(or sub-class) for each of these properties.
We have other internal tasks tracking these TODOs, let's not try to address those in the context of this PR.
I think you made this change to have the tests below with sigv4a. The supported way to do that is putAuthScheme
on the clientBuilder. (also note that's also at client level not request level which is what this TODO is about).
Modifications
Screenshots (if appropriate)
Types of changes
Checklist
mvn install
succeedsscripts/new-change
script and following the instructions. Commit the new file created by the script in.changes/next-release
with your changes.License