I tried enabling CORS for my API and I run into ... well, a ton of problems.
add-cors-header.js assumes that all keys under each path are HTTP methods (get, post etc), but there are other allowed keys here as well such as parameters. This made the plugin throw an error due to /somepath.parameters.responsesbeing undefined. I've made a PR for this if interesting?
add-cors-response-parameters throws if the x-amazon-apigateway-integration object doesn't have any responses collection. It's true that serveless integration create creates stubs with responses set to a simple map of status codes, but in some moment of clarity stupidity I seem to have removed these collections from my integrations since I noticed it could deploy without them. I made a PR that adds this collection just-in-time during CORS injection, if interesting?
add-cors-header.js adds headers to each response under each method's responses collection - but if a response is using a $ref to re-use a response such as #/components/responses/SomeResponse, the resulting document is invalid since the headers are added as a sibling to a $ref.
If the API uses contentHandling: CONVERT_TO_BINARY anywhere, I found that I had to add contentHandling: CONVERT_TO_TEXT to the cors integrations. Sure, this can be done through a custom integrations file, but since I doubt it will do any harm to always have it in there I suggest adding it to the default integrations.yml template in this library?
The third problem here need some thinking. When I simply ignored headers the deploy fails because the CORS header under responseParameters in each integration apparently must also be specified in the response headers. So... how to inject headers into a response which is a $ref? Should the document be dereffed first? It will become absolutely huge if the entire document is dereffed, so either deref just any referenced responses - or inject the headers into the reused response object itself (and assume it applies everywhere that response is referenced)? Thoughts? I prototyped this latter solution (injecting the headers into every response under components.responses and the API was deployed fine at least, so maybe that works. I don't see any reason why any response should omit the CORS headers, so why not?
I tried enabling CORS for my API and I run into ... well, a ton of problems.
add-cors-header.js
assumes that all keys under each path are HTTP methods (get
,post
etc), but there are other allowed keys here as well such asparameters
. This made the plugin throw an error due to/somepath.parameters.responses
being undefined. I've made a PR for this if interesting?add-cors-response-parameters
throws if thex-amazon-apigateway-integration
object doesn't have anyresponses
collection. It's true thatserveless integration create
creates stubs withresponses
set to a simple map of status codes, but in some moment ofclaritystupidity I seem to have removed these collections from my integrations since I noticed it could deploy without them. I made a PR that adds this collection just-in-time during CORS injection, if interesting?add-cors-header.js
addsheaders
to each response under each method'sresponses
collection - but if a response is using a$ref
to re-use a response such as#/components/responses/SomeResponse
, the resulting document is invalid since the headers are added as a sibling to a$ref
.If the API uses
contentHandling: CONVERT_TO_BINARY
anywhere, I found that I had to addcontentHandling: CONVERT_TO_TEXT
to the cors integrations. Sure, this can be done through a custom integrations file, but since I doubt it will do any harm to always have it in there I suggest adding it to the defaultintegrations.yml
template in this library?The third problem here need some thinking. When I simply ignored headers the deploy fails because the CORS header under
responseParameters
in each integration apparently must also be specified in the response headers. So... how to inject headers into a response which is a$ref
? Should the document be dereffed first? It will become absolutely huge if the entire document is dereffed, so either deref just any referenced responses - or inject the headers into the reused response object itself (and assume it applies everywhere that response is referenced)? Thoughts? I prototyped this latter solution (injecting the headers into every response undercomponents.responses
and the API was deployed fine at least, so maybe that works. I don't see any reason why any response should omit the CORS headers, so why not?