Override RegionSet in EnpointResolverInterceptor after fetching the Signing Properties from Endpoint rules #5825
Conversation
…igning Properties from Endpoint rules
joviegas
force-pushed
the
joviegas/resolve-regioset-after-endpoints
branch
from
e5fb5b7 to
5953fdf
Compare
| @@ -187,8 +201,7 @@ public void async_endpointProviderReturnsHeaders_appendedToExistingRequest() { | |||
| assertThat(interceptor.context.httpRequest().matchingHeaders("TestHeader")).containsExactly("TestValue", "TestValue0"); | |||
| } | |||
|
|
|||
| // TODO(sra-identity-auth): Enable for useSraAuth=true | |||
| /* | |||
|
|
|||
There was a problem hiding this comment.
Uncommented these test cases
|
| @@ -74,7 +74,8 @@ public static Metadata constructMetadata(ServiceModel serviceModel, | |||
| .withJsonVersion(serviceMetadata.getJsonVersion()) | |||
| .withEndpointPrefix(serviceMetadata.getEndpointPrefix()) | |||
| .withSigningName(serviceMetadata.getSigningName()) | |||
| .withAuthType(AuthType.fromValue(serviceMetadata.getSignatureVersion())) | |||
| .withAuthType(serviceMetadata.getSignatureVersion() != null ? | |||
There was a problem hiding this comment.
The specifications states
The authType and signatureVersion traits will be deprecated in favor of the auth and unsignedPayload traits.
Thus for new services which will be completed based on multi-auth signatureVersion will be null.
I added a test case for in codegen-tst when a new service is added with just multi-auth supporting only sigv4a
| @@ -219,7 +227,11 @@ private MethodSpec modifyRequestMethod(String endpointAuthSchemeStrategyFieldNam | |||
| SelectedAuthScheme.class, SdkInternalExecutionAttribute.class); | |||
| b.beginControlFlow("if (endpointAuthSchemes != null && selectedAuthScheme != null)"); | |||
There was a problem hiding this comment.
Is selectedAuthScheme ever null nowadays? It feels like this should be a dead code branch now?
There was a problem hiding this comment.
Removed this check
| if (multiAuthSigv4a) { | ||
| code.beginControlFlow("if (!hasRegionSet(selectedAuthScheme) && v4aAuthScheme.signingRegionSet() != null)"); | ||
| } else { | ||
| code.beginControlFlow("if (v4aAuthScheme.signingRegionSet() != null)"); | ||
| } |
There was a problem hiding this comment.
hasRegionSet seems like a relatively small method. Same with updateAuthSchemeWithRegionSet. Do we want to just always generate those methods, so that we don't have to do this branching in the code generator? It feels simpler to have a single code path regardless of sigv4a or sigv4 (both in the code generator, and in the generated code).
| if (!hasRegionSet(selectedAuthScheme) && v4aAuthScheme.signingRegionSet() != null) { | ||
| RegionSet regionSet = RegionSet.create(v4aAuthScheme.signingRegionSet()); | ||
| option.putSignerProperty(AwsV4aHttpSigner.REGION_SET, regionSet); | ||
| } |
There was a problem hiding this comment.
If I'm remembering the priorities right from the discussion with Alex, the endpoint provider's setting takes precedence over the auth scheme resolver's setting. This looks like we're favoring the auth scheme resolver. Am I misreading or misremembering?
There was a problem hiding this comment.
The discussion covered two distinct concepts: Signing Region and RegionSet. The current implementation specifically addresses SigV4a RegionSet, where Endpoint Parameters have the lowest precedence according to the Multi-auth specification. The precedence order is documented in the attached table.
Motivation and Context
The Sigv4a signing region set should be resolved based on below sepecifications
Sigv4a signing region set resolution
Configuration follows the same resolution order as other client configuration
options, where more specific configuration is preferred over less specific. The
following table shows cases that demonstrate this. Each column except for
Resultshows a source for the signing region set, andResultis the valuethat should be used. Note that
*indcates the request is valid in all regions.Modifications
Testing
Screenshots (if appropriate)
License