Custom Header in Options Preflight For Cors

Serverless Framework
1

Here’s my serverless.yml

  custom:
    allowed-headers:
      - Content-Type
      - X-Amz-Date
      - Authorization
      - X-Api-Key
      - X-Amz-Security-Token
      - X-Amz-User-Agent
      - X-Cowabunga      functions:
    Registration:
      handler: ArmaBackending::Backckending.MahAPI::Register
      role: superSpecialRole
      events:
        - http:
            path: sillyputty
            method: post
            cors:
              origin: "*"
              headers: ${self:custom.allowed-headers}
              allowCredentials: true
    RetrieveDetails:
      handler: ArmaBackending::Backckending.MahAPI::Details
      role: superSpecialRole
      events:
        - http:
            path: sillyputty/puttysilly
            method: get
            request:
              parameters:
                paths:
                  type: true
            cors:
              origin: "*"
              heanders: ${self:custom.allowed-headers}
              allowCredentials: true
  • For POST [URL]/sillyputty, the CORS OPTIONS preflight returns the correct Access-Control-Allow-Headers specified in the self:custom.allowed-headers. i. e.: Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,X-Amz-User-Agent,X-Cowabunga
  • However, GET [URL]/sillyputty/puttysilly, the CORS OPTIONS preflight returns the default Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,X-Amz-User-Agent
  • I can observe the Header Mappings exhibiting the above in Access-Control-Allow-Headers in API-Gateway Dashboard.

Can someone help me to understand what I did wrong?

Thank you very much!

2

heanders is mispelled =)

heanders: ${self:custom.allowed-headers}

3

That’s a fantastic catch, @DavidWells!
Gosh, i must be overworked!
Thank you so much! It’s totally working after all!
(sorry for the exclamation marks, i m rather excitable)

1 Like