2 Answers
- Newest
- Most votes
- Most comments
0
Thanks Marco! However the swagger specification references an arn... of the authorizer. Do I need to create the authorizer first in cdk, then do a replace in the swagger/openapi and then create the api from the swagger spec?
answered 2 years ago
0
When you define your API via OpenAPI you have to use the OPenAPI Extension to define the authorizer in your definition. https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions-authtype.html
answered 2 years ago
Thanks Marco! However the swagger specification references an arn... of the authorizer. Do I need to create the authorizer first in cdk, then do a replace in the swagger/openapi and then create the api from the swagger spec?
Relevant content
- Accepted Answerasked 2 years ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 10 months ago
- AWS OFFICIALUpdated 2 years ago
Yes, this is one way to do it. The service team is aware of that issue but i have no date if and when this get´s fixed. Another option is to get all the methods from the api and overwrite the method options.
But in general I would challenge what are the benefits defining the API as OpenAPI definition and is it worth the additional overhead you have with your Stack. You can also define your API with CDK Constructs and then export the Swagger Definition from your Stage.
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html
Not sure what is happening with re:Post... account created but lost.. anyway:
Hi Marco!
Thanks for the reply, good to know I am not overlooking something ;-) I have managed to find a solution at the moment (create authorizer, replace placeholder, create api through spec ). The issue we are facing is that we have teams working in AWS and teams working in Interfaces/Integration. The latter are no coders and have no knowledge about AWS and therewith the CDK. They do know Swagger and OpenApi and want to be in control of that part. With this in mind we want to use those specs as leading assets for the API. The reason I said overlooking was because something similar is possible with a Resource Policy, where AWS resolves the resource with the correct ARN. Anyway for now I am good, so hopefully a fix will find its way into the spec for resolving it automatically.