CORS failure in preflight requests, despite setting cors:true in serverless.yml

Serverless Framework
, , ,
1

My preflight requests are failing with 403 errors, even the GET requests. I’m trying to get the notes example working in Serverless Stack 3.1 PDF. What are some suggestions for how to troubleshoot this?

Here’s my serverless.yml:

  get:
    handler: src/get.main
    events:
      - http:
          path: notes/{id}
          method: get
          cors: true
          authorizer: aws_iam

Here’s the code I’m using to make the API call:

      AWS.config.getCredentials(async () => {
        console.log ('Cognito got credentials')
        // The user is authenticated. Let's try to read and write to the database!
        try {
          const result2 = await API.get('notes', '/notes/3d21cb80-9cec-11e8-a3d7-a54868cd7509', {});
          const resultJson2 = JSON.stringify(result2);
          console.log(resultJson2);
        } catch (e) {
          console.log(`API error: ${e}`);
        }
      });

Here’s the headers on the OPTIONS preflight request:

Request URL:
https://jrq08ushmh.execute-api.us-east-2.amazonaws.com/notes/3d21cb80-9cec-11e8-a3d7-a54868cd7509

Request Method:
OPTIONS

Status Code:
403

Remote Address:
52.85.80.42:443

Referrer Policy:
no-referrer-when-downgrade

Response Headers
content-type: application/json

Request Headers  (Provisional headers are shown)
Access-Control-Request-Headers: authorization,x-amz-date,x-amz-security-token
Access-Control-Request-Method: GET

Origin:
http://localhost:3000

User-Agent:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36

When I call the OPTIONS endpoint directly using the AWS test tool, the OPTIONS request seems to return correct output. Here’s the output:

Request: /notes/3d21cb80-9cec-11e8-a3d7-a54868cd7509

Status: 200

Latency: 6 ms

#### Response Body

```
no data
```

#### Response Headers

```
{"Access-Control-Allow-Origin":"*","Access-Control-Allow-Credentials":"false","Access-Control-Allow-Methods":"OPTIONS,GET","Access-Control-Allow-Headers":"Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,X-Amz-User-Agent","Content-Type":"application/json"}
```

#### Logs

```
Execution log for request da1d40d5-9cf9-11e8-b72b-3beab7bcc8f0
Sat Aug 11 00:02:35 UTC 2018 : Starting execution for request: da1d40d5-9cf9-11e8-b72b-3beab7bcc8f0
Sat Aug 11 00:02:35 UTC 2018 : HTTP Method: OPTIONS, Resource Path: /notes/3d21cb80-9cec-11e8-a3d7-a54868cd7509
Sat Aug 11 00:02:35 UTC 2018 : Method request path: {id=3d21cb80-9cec-11e8-a3d7-a54868cd7509}
Sat Aug 11 00:02:35 UTC 2018 : Method request query string: {}
Sat Aug 11 00:02:35 UTC 2018 : Method request headers: {}
Sat Aug 11 00:02:35 UTC 2018 : Method request body before transformations: 
Sat Aug 11 00:02:35 UTC 2018 : Received response. Integration latency: 0 ms
Sat Aug 11 00:02:35 UTC 2018 : Endpoint response body before transformations: 
Sat Aug 11 00:02:35 UTC 2018 : Endpoint response headers: {}
Sat Aug 11 00:02:35 UTC 2018 : Method response body after transformations: 
Sat Aug 11 00:02:35 UTC 2018 : Method response headers: {Access-Control-Allow-Origin=*, Access-Control-Allow-Credentials=false, Access-Control-Allow-Methods=OPTIONS,GET, Access-Control-Allow-Headers=Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,X-Amz-User-Agent, Content-Type=application/json}
Sat Aug 11 00:02:35 UTC 2018 : Successfully completed execution
Sat Aug 11 00:02:35 UTC 2018 : Method completed with status: 200
```
1 Like
2

It is possible that the url used is not correct. I.e. if you try to access end point like
https://{apiGatewayPath}/users instead of the right one https://{apiGatewayPath}/{EnvironmentName}/users you will be getting 403 for OPTIONS request.

3 Likes
3

Yep, that was it. Thanks @autushka!