Serverless-application-model: CORS issue when using OAS3 spec for Serverless::Api

Created on 16 Oct 2018  路  19Comments  路  Source: aws/serverless-application-model

Description:

Tried to convert my API over tonight from swagger 2.0 to openapi specification 3.0, and got an error at the Cloudformation Changeset creation and SAM transformation step. This might be due to the use of CORS in our template to modify the openapi file.

Steps to reproduce the issue:

  1. Take a working API, deployed to a stage
  2. goto Stages > Export > Select 'Export as OpenAPI 3'
  3. Delete the extraneous 'options' methods in the file
  4. Validate swagger syntax and format using swagger-cli v2.1.3
  5. In the SAM template.yml, use CORS and DefinitionBody (ex below)
MyApi:
    Type: AWS::Serverless::Api
    Properties:
      ...
      Cors:
        AllowOrigin: "'*'"
        AllowMethods: "'*'"
        AllowHeaders: "'*"
      DefinitionBody:
          'Fn::Transform':
            Name: 'AWS::Include'
            Parameters:
              Location: !Sub 's3://path-to-oas/oas3.yml'
  1. Run command, aws cloudformation package etc
  2. Should fail with the following

Observed result:
Failed to create the changeset: Waiter ChangeSetCreateComplete failed: Waiter encountered a terminal failure state Status: FAILED. Reason: Transform AWS::Serverless-2016-10-31 failed with: Invalid Serverless Application Specification document. Number of errors found: 1. Resource with id [MyApi] is invalid. Unable to add Cors configuration because 'DefinitionBody' does not contain a valid Swagger

Expected result:
Changeset to be created, ready for aws cloudformation deployment.

areserverless-api contributorneed-help priorit2-important

Most helpful comment

Thanks! We'll get this scheduled to support OAS3

All 19 comments

Yup, us too. Looks like https://github.com/awslabs/serverless-application-model/blob/master/samtranslator/swagger/swagger.py#L301 needs to be updated (thanks to @johnchapin for finding that)

Thanks! We'll get this scheduled to support OAS3

any update on this issue?

Anything new?

Adding a priority label to help us get this scheduled soon. Sorry for the wait.

I'm not personally familiar with OAS3; could someone direct me to something that explains the differences between it and Swagger so I can better understand what needs to change to support it? Can I still use swagger syntax and call it OAS3 instead of Swagger 2.0?

@keetonian I'm aware of only two impacts for SAM:

  1. Instead of swagger: '2.0' in the DefinitionBody, it will be openapi: '3.0'. The change for SAM for this should be just allowing openapi: '3.0' when the translator performs validation checks.

  2. For API authorizers, there is a slight difference in what gets added to the DefinitionBody: SecurityDefinitions changes to SecuritySchemas in openapi 3.0 (Example here: https://docs.amazonaws.cn/en_us/apigateway/latest/developerguide/apigateway-enable-cognito-user-pool.html).

Bumping this is this in the pipeline for development? It would seem especially relevant now that API gateway itself supports Open Api 3?

adding a +1 here, was ecstatic to remove some code that converted OAS3 to OAS2, but really sad to run into this issue. For my specific need, I am wanting to utilize OAS3's oneOf feature to indicate that an API endpoint has different responses for a 200 request.

+1 as well, we are running into the same issue.

+1

+1

+1

We prioritize a lot based on +1 reactions. Commenting with +1 isn't helpful.

@txase thanks for the comment on what you think are the main (only?) required changes. This is definitely on our radar, however, if someone wants to send a PR it'll go faster. Right now I'm thinking we simply expose an OASVersion property and perform these slight adjustments based on that.

Is there a workaround for now?

Released with v1.13.0

same issue

This issue is being tracked in #1161

Was this page helpful?
0 / 5 - 0 ratings