-
Notifications
You must be signed in to change notification settings - Fork 597
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
feat: support Sigv4 for non AWS services #2385
Conversation
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.
Why is this bifurcation needed? It looks to me like all you're doing is avoiding the region provider, but should you?
EDIT: I may be confusing two things. A region provider can be a thing that pulls the region from, say, environment variables or EC2 metadata. Or it could be the thing that uses the region to resolve an endpoint. The latter we definitely want to cut out, but the former should be kept if possible. If they're inextricably linked then I guess we have no choice, but it'd be good to leave a todo so we can explore splitting them up in the future.
if (isAwsService(settings, model)) { | ||
writer.writeDocs("The AWS region to which this client will send requests") | ||
.write("region?: string | __Provider<string>;\n"); | ||
} else { | ||
writer.writeDocs("The AWS region to use as signing region for AWS Auth") | ||
.write("region?: string | __Provider<string>;\n"); | ||
} |
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.
Writing the actual region can be outside of this block since it doesn't change.
EDIT: actually it seems like the rest of the changes in this PR serve to effectively make region required, so I guess you'd want to enforce that here
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 had the if
to write a specific comment in each case.
It is not required in the sense that you don't need to provide it when instantiating the client. It is link for AWS clients where it comes in to ClientDefaultValues from here
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.
Yes, but you can do that and still write the region separately. The methods in TypeScriptWriter
return the object so you can chain calls like this, but it's not necessary.
...t-codegen/src/main/java/software/amazon/smithy/aws/typescript/codegen/EndpointGenerator.java
Outdated
Show resolved
Hide resolved
I guess you are asking about bifurcation of AwsAuth v/s CustomAwsAuth. Yeah it's the latter. The RegionInfoProvider determines the endpoint and signingService, signingRegion. |
Based on discussion with @AllanZhengYP,
I'm going to call this SigV4Auth (for non-AWS services) and AwsAuth will represent SigV4 auth for AWS services.
It seems safe to add signingName for every AWS service. I'll mark it |
There is no regionInfo to determine signingService. The signingName will instead directly come from input. And region will be used as signingRegion.
Write `signingName` from the SigV4 trait for non AWS service. `region` is used for the signingRegion. A separate SigV4Auth is used for SigV4 logic for non AWS services.
Codecov Report
@@ Coverage Diff @@
## main #2385 +/- ##
=======================================
Coverage ? 59.00%
=======================================
Files ? 484
Lines ? 26078
Branches ? 6192
=======================================
Hits ? 15387
Misses ? 10691
Partials ? 0 Continue to review full report at Codecov.
|
The models for the protocol tests don't seem to have the SigV4 trait, so can't rely solely on it for using the Region plugin. e.g, https://github.com/awslabs/smithy/blob/main/smithy-aws-protocol-tests/model/restJson1/main.smithy#L11-L13
@@ -226,7 +226,7 @@ export interface ClientDefaults extends Partial<__SmithyResolvedConfiguration<__ | |||
serviceId?: string; | |||
|
|||
/** | |||
* The AWS region to which this client will send requests or use as signingRegion | |||
* The AWS region to which this client will send requests |
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.
These are basically going back what the comment was before some of my earlier changes. See
* The AWS region to which this client will send requests |
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.
Still have that one splitup comment, but all good after that.
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 looks good to me! I only found some files changed unexpectly.
"x-long": "123", | ||
"x-byte": "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.
I don't think this change is needed.
"x-memberepochseconds": "1576540098", | ||
"x-defaultformat": "Mon, 16 Dec 2019 23:48:18 GMT", |
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.
This change is not needed.
"x-long": "123", | ||
"x-byte": "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.
This change is not needed.
"x-memberepochseconds": "1576540098", | ||
"x-defaultformat": "Mon, 16 Dec 2019 23:48:18 GMT", |
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.
This change is not needed.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread. |
Description
This has changes to
middleware-signing
andcodegen
to support generating clients for non AWS services that have SigV4 auth.Testing
I generated client for the bootleg demo service we are working on and with SigV4 enabled on the service, confirmed the client is able to successfully call it. See https://github.com/adamthom-amzn/smithy-typescript-ssdk-demo/pull/20 for testing details.
I ran
yarn generate-clients
. There is only a change is comment for all generated clients, but it is actually going back to what it was few weeks back before my earlier changes for supporting non AWS services changed the comment slightly.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.