Search code examples
amazon-web-servicesaws-lambdaamazon-cognitoserverless-frameworkserverless-plugins

Serverless Framework AWS 403 Forbidden Error with Domain Only


I am working on a serverless setup for a project and ran into a strange error. This was working fine before I had to delete my old certificates and make a new one.

In short, I am following the tutorial series at serverless-stack.com for reference, and when running the apig-test command I get the following error.

{ status: 403,
  statusText: 'Forbidden',
  data: { message: 'Forbidden' } }

This screams to me policy error. So I went to check my policy to make sure it allows execution for the AuthRole and indeed it does. I verified this in IAM section under Roles and looked my services Auth_Role that I created when I set up Cognito.

I don't want to give information overload here, but if anyone has any ideas for where to look next I would be much appreciative and I'll give any details you want to see here.

One thing I want to note is that if I run the apig-test command with the direct URL to the Lambda function instead of my domain it works perfectly fine.

This proves that nothing is wrong with my code but more a policy setting regarding how I setup the domain.

I ran sls create_domain accordingly and I see the entries in the Route53 & API Gateway and they have finished their 40 minutes many hours ago. I insured its using correct certificate since I wiped out the other one.

My custom domains have worked in the past thanks to a plugin I found and this tutorial here (https://serverless.com/blog/serverless-api-gateway-domain/), its only recently that it stopped working when I realized I needed to add some more domains to my SSL cert.

So I assume the policy error is somewhere around this but not sure where to look?


Solution

  • Ok I found the answer. In the API Gateway under custom domains there is a section called Base Path Mappings This MUST be set to one of your functions with the default path of / (or just enter nothing for the path) and then the destination to your lambda service. This seemed to make it work for me.