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.jsassumes that all keys under each path are HTTP methods (get,postetc), but there are other allowed keys here as well such asparameters. 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-parametersthrows if thex-amazon-apigateway-integrationobject doesn't have anyresponsescollection. It's true thatserveless integration createcreates stubs withresponsesset 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.jsaddsheadersto each response under each method'sresponsescollection - but if a response is using a$refto 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_BINARYanywhere, I found that I had to addcontentHandling: CONVERT_TO_TEXTto 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.ymltemplate in this library?The third problem here need some thinking. When I simply ignored headers the deploy fails because the CORS header under
responseParametersin 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.responsesand 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?