Manually created CORS-enabled Proxy API leads to different config in SAM

[alex-harvey-z3q]

Description:

When deploying an implicit API with SAM and then doing what I take to be the same steps in API Gateway in the AWS Console, I end up with a different configuration. To be sure, I'm not sure if this is a support request or a behaviour that needs better documentation or a bug.

Steps to reproduce the issue:

1/ In Console, create a Proxy resource. Steps: Go to API Gateway => Create API => (Name=MyAPI, Endpoint Type=Edge Optimized). Then: Actions => Create Resource => (Configure as Proxy resource, leave Enable API Gateway CORS UNchecked) => Create Resource. Then: Lambda Function=Some Lambda Function. Then: Save. Then: Select the /{proxy+} resource => Actions => Enable CORS => (Gateway Responses for MyAPI API=Default 4XX,Default 5XX) => Enable CORS and replace existing CORS headers.

2/ In a SAM template:

Globals:
  Api:
    EndpointConfiguration: EDGE
    Cors:
      AllowMethods: "'DELETE,GET,HEAD,OPTIONS,PATCH,POST,PUT'"
      AllowHeaders: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token'"
      AllowOrigin: "'*'"
Resources:
  ChatAPIFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: my-api/
      Handler: index.handler
      Runtime: nodejs8.10
      Policies: AmazonS3ReadOnlyAccess
      Events:
        ProxyApiGreedy:
          Type: Api
          Properties:
            Path: /{proxy+}
            Method: ANY

Observed result:

For the manually create API I see in the Method Response "Models: application/json => Empty" as shown here:

For the SAM-created API I don't see the Models:

Expected result:

I expected both these approaches to result in the same config, and if not, I expected to be able to somehow use SAM to generate the same config I generated manually.

Additional info:

This may be related to #640

[brettstack]

I think the API Gateway Console creates the Model for you. You can explicitly create the model using CloudFormation if you need to, though I think you will then need to manually create your OPTIONS method to use that model.

[alex-harvey-z3q]

Thanks for the response @brettstack. In addition to this, I found that the Response Headers are missing in the Gateway Responses section too:

Manual:

Via SAM:

That looks more serious?

[lukpep]

any info on this? I'm also unable to set cors on sam created API.
This example:
https://github.com/aws-samples/startup-kit-serverless-workload/blob/master/serverless.cfn.yml

still leads to missing headers and I'm unable to consume my sam crated API in SPA due to CORS.

[chrisoverzero]

When you say that the headers are missing, do you mean in the preflight response or in the actual application response? SAM (really, API Gateway) cannot add CORS headers to the responses returned by the application. The CORS settings apply to preflight responses – that is, the responses to the OPTIONS-with-some-headers requests that precede the actual request by the browser. The other kind have to be included by the application code itself.

[lukpep]

yep true - also worth mentioning is the fact that default authorizer is also applied to the OPTIONS requests... so I ended up with two things (making it work):

• added obligatory CORS headers into responses directly in a functions code
• removed my custom authorization from `DefaultAuthorizer' and manually marked events in function definition with it - so the authorization is not applied to preflight requests.

[praneetap]

Thanks for your comment @lukpep! This change removed the default authorizer from being added to options method, and it should fix it for you. Here is an example on how to use it.

[didopop3]

yep true - also worth mentioning is the fact that default authorizer is also applied to the OPTIONS requests... so I ended up with two things (making it work):

• added obligatory CORS headers into responses directly in a functions code
• removed my custom authorization from `DefaultAuthorizer' and manually marked events in function definition with it - so the authorization is not applied to preflight requests.

Hi @lukpep I have returned CORS headers into responses directly in a functions code, but after the deploy with a sam template, the cors is still not working.

Is it just me? or have you got it fixed? Could you please share more information.

Thanks!

[gnestor]

I'm seeing the same thing as @didopop3.

I have the following in the Globals section:

 Api:
    Cors:
      AllowOrigin: "'*'"
      AllowMethods: "'*'"
      AllowHeaders: "'*'"

and I'm explicitly returning CORS headers in my function code:

return {
  body: 'Unprocessable',
  statusCode: '204',
  headers: {
    'Access-Control-Allow-Origin': headers.Origin,
    'Content-Type': 'text/plain',
  }
}

When running locally, CORS headers are included in responses, but when running in production, POST requests are not including the CORS headers in responses (while OPTIONS pre-flights responses are).

[hatchstartups-tech]

Any update on this, If we upload our SAM Application will not work because of CORS, but if via de console you recreate the API's then they work, this is not maintainable since the SAM its a yaml you could maintain with PR's and code change management, if its only via the console, once you re-upload the SAM for whatever reason, all the configuration made on the console gets lost.