-
-
Notifications
You must be signed in to change notification settings - Fork 7k
[typescript-axios] Add support for AWSv4 Signature #18215
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
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -16,7 +16,7 @@ import FormData from 'form-data' | |
{{/withNodeImports}} | ||
// Some imports not used depending on template conditions | ||
// @ts-ignore | ||
import { DUMMY_BASE_URL, assertParamExists, setApiKeyToObject, setBasicAuthToObject, setBearerAuthToObject, setOAuthToObject, setSearchParams, serializeDataIfNeeded, toPathString, createRequestFunction } from '{{apiRelativeToRoot}}common'; | ||
import { DUMMY_BASE_URL, assertParamExists, setApiKeyToObject, setBasicAuthToObject, setBearerAuthToObject, setOAuthToObject, setSearchParams, serializeDataIfNeeded, toPathString, createRequestFunction{{#withAWSV4Signature}}, setAWS4SignatureInterceptor{{/withAWSV4Signature}} } from '{{apiRelativeToRoot}}common'; | ||
// @ts-ignore | ||
import { BASE_PATH, COLLECTION_FORMATS, RequestArgs, BaseAPI, RequiredError, operationServerMap } from '{{apiRelativeToRoot}}base'; | ||
{{#imports}} | ||
|
@@ -71,6 +71,10 @@ export const {{classname}}AxiosParamCreator = function (configuration?: Configur | |
{{#authMethods}} | ||
// authentication {{name}} required | ||
{{#isApiKey}} | ||
{{#withAWSV4Signature}} | ||
// aws v4 signature authentication required | ||
await setAWS4SignatureInterceptor(globalAxios, configuration) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It looks like this sets the interceptor to the shared axios instance - affecting all requests made with axios in the app
I really think the security settings should be applied per endpoint rather than globally There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do you think the best way to achieve this? Would it be creating a "shared" axios instance just for the aws4 secured endpoints? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I personally like option 2 best. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Option 4: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This is exactly my use case and to me it makes sense since an SDK that is built for inter-service communication only defines endpoints that are meant for such scenario and not any other. In my experience also an SDK uses a single type of authentication/authorization type and not multiple ones. Otherwise it's going to be a complex setup to handle. Shall we go with option 4? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I mean, in this case perhaps you don't need any change in openapi-generator - you can set the global interceptor directly in your app |
||
{{/withAWSV4Signature}} | ||
{{#isKeyInHeader}} | ||
await setApiKeyToObject(localVarHeaderParameter, "{{keyParamName}}", configuration) | ||
{{/isKeyInHeader}} | ||
|
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.
What if instead of requiring a user to explicitly opt in, we derive it from the actual spec? If the spec uses aws4 security, we add the corresponding dependency to the generated code.
Is there a use case where a spec relies on AWS4, but a user want to opt out? Or vice versa - the spec doesn't use AWS4, but we still want to include it in the generate files?
Uh oh!
There was an error while loading. Please reload this page.
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 personally don't have such use case since my workflow would be creating two different SDKs for each scenario. Scenario A would be an SDK that is exclusive for inter-service communication (IAM authorized) and scenario B would be creating a separate SDK for a frontend client that would have the a bearer token (i.e Cognito User Pool) authentication/authorisation security on it.
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.
K I'm going to be taking this effort over.
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.
@amakhrov Detecting AWS Auth from the schema PR #21356