Upgrading from 1.24 to 1.26 serverless, AWS signature validation fails when invoking lamda function

Serverless Framework
1

Hi,

To set the context to the question the scenario is as below for AWS:

  1. API Gateway with lambda integration ( NOT proxy )
  2. Has custom authorizer which looks up Bearer token in “Authorization” header.

Serverless.yml file has below configuration

  hello:
    handler: handler.hello
    events:
      - http:
          name: ${opt:stage}-jstest
          path: /
          method: get
          cors:
           origins:
             - '*'
           headers:
             - Content-Type
             - X-Amz-Date
             - Authorization
             - X-Api-Key
             - X-Amz-Security-Token
           methods:
             - GET
             - OPTIONS
          integration: lambda
          authorizer:
              name: authorizerFunction
              resultTtlInSeconds: 300
              identitySource: method.request.header.Authorization
          request:
            parameters:
             headers:
               Authorization : true

Issue statement: When I add headers in request parameter to serverless.yml file, the header mapping is created for both method and integration ( in 1.26). However, the behaviour in version 1.24.1. is, it creates only in method but not in integration.

With the behavior as in 1.26, and with headers added to request parameters, the error we get when tested is as shown below.

“The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.”

Question: Is there anyway to add the request parameter headers only to method and not to integration?

Thanks
-Vasu

2 Likes
2

I’m also facing same issue.

We need to use existing apiGateway (https://github.com/serverless/serverless/pull/4247) as we ran out of 200 resource limit, so migrated to new version 1.26.1

If we deploy with this version it gives internal server error.
Guys, help will be really appreciated.

1 Like
3

image
image1328×286 8.31 KB

Here is the difference in template generated in both cases, for @jagdish-176 issue.

The RequestParameters Section is new, which was not there earlier.

4

image
image1249×367 67.2 KB

This code is introduces in 1.26 which is not in 1.24
If I comment it in the plugin and use it, what could be the effect.

Please note request parameters are already added in the properties section

line: 15 in $/serverless-master\lib\plugins\aws\package\compile\events\apiGateway\lib\method\index.js
const requestParameters = (event.http.request && event.http.request.parameters) || {};

There should be a separate flag for this?

Regards,
Adit

1 Like
5

@aditmalik, I believe the issue i mentioned is exactly because of this section of code. Probably we should allow the user to choose if he wants to propagate the mapping to integration request too.

1 Like
6

Seems this was done with the PR (https://github.com/serverless/serverless/pull/4665)

7

anyupdate, if this is going to be changed or modified or removed

8

can you raise an issue with details directly to github.com/serverless/serverless for this big?

9

Raised an issue in serverless

2 Likes
10

I raised an issue with AWS and they answered as below, " The internal server error" was raised because of “Signature mimatch” between API Gateway and Lambda. As API Gateway too uses “Authorization” header , the header gets corrupted if users too use it. AWS advised me not to use this header and use a different name.

I changed my header from “Authorization” to “AuthToken” and it worked in 1.26.1 serverless. Posting this is it can help anyone.

I believe this is just a work around and sls needs to fix this.

Thanks.
-Vasu

1 Like
11

Authorization, is a standard header tag, i don’t think renaming it right.

12

I agree, It would also require all your consumers to change their headers. I too gonna wait for sls to fix it.

13

Authorization is standard header tag, not mean you have to use the name. You can define to any other names if you want to do.

identitySource: method.request.header.x-abc-xyz
14

I have a written a serverless plugin for workaround while the team fixes it permanently.

You can do

npm install serverless-fix-apigw-int
Add this plugin to serverless.yml file.
deploy
Thanks

15

I have got it resolved by configuring the aws credentials using the below cmds:

  1. serverless config credentials --provider aws -k <your_access_key_id_here> -s <your_secret_access_key_here>

  2. export AWS_ACCESS_KEY_ID="<your_access_key_id_here>"
    export AWS_SECRET_ACCESS_KEY="<your_secret_access_key_here>"

16

If we deploy with this version it gives internal server error