Closed raj-milton closed 2 years ago
I had this problem the last couple days and finally got a fix just recently. Maybe I can dump a list of things that helped me:
x-api-key
headercustom.customDomain.endpointType
was edge
to match how my lambda was deployed, versus how I had it originally with regional
customDomain.stage
and customDomain.basePath
, because I found it uses the stage name by default, and it doesn't need the extra base pathHere's a cheesy variant of my serverless.yaml:
service:
name: cheese-results
custom:
webpack:
webpackConfig: ./webpack.config.js
includeModules: true
dotenv:
path: ./.env
basePath: ./
associateWaf:
name: ${env:ENV}-cheese-results
version: V2
customDomain:
domainName: cheese-results.${env:ENV}.megamaxcheeseshack.com
certificateName: ${self:custom.wildcardDomains.${env:ENV}}
createRoute53Record: true
endpointType: 'edge'
securityPolicy: tls_1_2
wildcardDomains:
dev: '*.dev.megamaxcheeseshack.com'
qa: '*.qa.megamaxcheeseshack.com'
hotfix: '*.hotfix.megamaxcheeseshack.com'
prod: '*.megamaxcheeseshack.com'
plugins:
- serverless-dotenv-plugin
- serverless-webpack
- serverless-associate-waf
- serverless-domain-manager
provider:
name: aws
runtime: nodejs12.x
region: us-east-2
timeout: 10
apiGateway:
minimumCompressionSize: 1024
usagePlan:
quota:
limit: 25000
period: WEEK
throttle:
rateLimit: 10
burstLimit: 20
apiKeys:
- value: ${ssm:/${env:ENV}/cheese-results/api-key~true}
environment:
CHEESY_VAR: cheddar
role: arn:aws:iam::000000000000:role/default-lambda-role-${env:ENV}
vpc:
subnetIds:
- subnet-00000000000000000
- subnet-11111111111111111
- subnet-22222222222222222
securityGroupIds:
- sg-99999999999999999
functions:
cheese-results:
handler: handler.consumeCheeseResults
events:
- http:
method: post
path: data
private: true
Then I could hit the lambda at both
https://r4ndomsss2.execute-api.us-east-2.amazonaws.com/dev/data
and
https://cheese-results.dev.megamaxcheeseshack.com/data
Hi @raj-milton
It's no activity for a long time and hope you have found a solution! The Serverless Domain Manager does not have logic that raises 403 errors, it should be handled via AWS.
Make sure you have specified all needed permissions for the plugin. From the Readme:
acm:ListCertificates *
apigateway:GET /domainnames/*
apigateway:GET /domainnames/*/basepathmappings
apigateway:DELETE /domainnames/*
apigateway:POST /domainnames
apigateway:POST /domainnames/*/basepathmappings
apigateway:PATCH /domainnames/*/basepathmapping
cloudformation:GET *
cloudfront:UpdateDistribution *
route53:ListHostedZones *
route53:ChangeResourceRecordSets hostedzone/{HostedZoneId}
route53:GetHostedZone *
route53:ListResourceRecordSets *
iam:CreateServiceLinkedRole arn:aws:iam::${AWS::AccountId}: role/aws-service-role/ops.apigateway.amazonaws.com/AWSServiceRoleForAPIGateway
Closing it but feel free to reopen in case of any related issues.
Thanks @dbirks I had this issue too. I had to add apiType: http and remove stage from my customDomain config (already had blank basePath). Mine worked on regional not edge though.
We are using serverless Pro to deploy our API. We have added a custom domain to the API gateway. When we are calling API with custom domain it is throwing 403 "Forbidden" error. But the AWS lambda endpoint gives us the successful results. Can you please provide a solution to this?