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

feat: support Sigv4 for non AWS services #2385

Merged
merged 7 commits into from
Jun 3, 2021
Merged

feat: support Sigv4 for non AWS services #2385

merged 7 commits into from
Jun 3, 2021

Conversation

gosar
Copy link
Contributor

@gosar gosar commented May 11, 2021

Description

This has changes to middleware-signing and codegen 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.

Copy link
Member

@JordonPhillips JordonPhillips left a 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.

Comment on lines 98 to 104
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");
}
Copy link
Member

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

Copy link
Contributor Author

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

Copy link
Member

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.

packages/middleware-signing/src/configurations.ts Outdated Show resolved Hide resolved
@gosar
Copy link
Contributor Author

gosar commented May 12, 2021

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.

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.

@gosar gosar requested a review from JordonPhillips May 12, 2021 20:45
@gosar
Copy link
Contributor Author

gosar commented May 13, 2021

Based on discussion with @AllanZhengYP,

  1. Any alternate naming suggestions for CustomAwsAuth?

I'm going to call this SigV4Auth (for non-AWS services) and AwsAuth will represent SigV4 auth for AWS services.

  1. There was existing reference to input.signingName in middleware-signing but I couldn’t see how one provides that input configuration. Is it safe to add signingName in config interface for every AWS service?

It seems safe to add signingName for every AWS service. I'll mark it @internal. The existing logic was probably based on assumption that the AWS service model may not have SigV4 trait, or it didn't exist back then. Given that now SigV4 trait is going to be present for every AWS service, we could just rely on that value instead of value from RegionInfoProvider(RIP). But that cleanup for AWS services, can be handled separately. I'm only going to change the logic for non-AWS service in this PR.

gosar added 2 commits May 13, 2021 10:57
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-commenter
Copy link

codecov-commenter commented May 13, 2021

Codecov Report

❗ No coverage uploaded for pull request base (main@597e689). Click here to learn what that means.
The diff coverage is n/a.

Impacted file tree graph

@@           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.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 597e689...36fcace. Read the comment docs.

@@ -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
Copy link
Contributor Author

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

Copy link
Member

@JordonPhillips JordonPhillips left a 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.

@gosar gosar requested a review from JordonPhillips May 25, 2021 21:22
Copy link
Contributor

@AllanZhengYP AllanZhengYP left a 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",
Copy link
Contributor

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",
Copy link
Contributor

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",
Copy link
Contributor

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",
Copy link
Contributor

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.

@gosar gosar requested a review from AllanZhengYP June 3, 2021 21:40
@gosar gosar merged commit 0a251aa into aws:main Jun 3, 2021
@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 18, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants