For a while we’ve used a setup where multiple serverless files use the same Api Gateway and share authorizers that are defined in a separate cloudformation stack. We’ve used authorizer type = “CUSTOM” and an authorizerId to point to an existing authorizer, but upon upgrading to serverless v2 I get an error saying: Configuration warning at 'functions.get.events[0].http.authorizer.type': unsupported configuration format
A typical template looks like this:
service: my-test-service
provider:
name: aws
region: eu-west-1
stage: prod
runtime: python3.7
apiGateway:
restApiId: fjei400f
restApiRootResourceId: af4i4i
functions:
get:
handler: handler.handle_stuff
events:
- http:
path: my-path
method: get
authorizer:
type: CUSTOM
authorizerId: aliwjefij3
But it works just as expected. Is there a bug in the schema definition for the api gateway authorizer setup?
Here is the corresponding Cloudformation docs that confirm that CUSTOM is the right type:
Hi
I am having the same warning, did you find how to remove it?
CUSTOM
doesn’t appear to be a valid authorizer type.
From the AWS API Gateway Authorizer Reference:
Type
The type of authorizer. Valid values include:
* TOKEN: A custom authorizer that uses a Lambda function.
* COGNITO_USER_POOLS: An authorizer that uses Amazon Cognito user pools.
* REQUEST: An authorizer that uses a Lambda function using incoming request parameters.
the log error have this:
An error occurred: ApiGatewayMethodPartclassSearchPost - Invalid AuthorizationType specified. Valid options are NONE,AWS_IAM,CUSTOM,COGNITO_USER_POOLS,AWS_CROSS_ACCOUNT_IAM,JWT (Service: AmazonApiGateway; Status Code: 400; Error Code: BadRequestException; Request ID: 2bc0e89f-26f9-4497-9207-2f8d33f735d1; Proxy: null).
@bfieber thanks for the reply! As far as I can understand those types go for the actual authorizer, where the config I mentioned is where you reference an authorizer to be used for a specific Method. See the link in the bottom of my post.
@jayceesnow Unfortunately I didn’t find a way passed this (other than turning of all validation using configValidationMode: error). Thanks anyway for confirming that I’m not the only one struggling with this. I guess the right way forward would be to make an issue / a PR in the serverless repo.
Looks like a potential bug in the SLS code.
In v2.5.0 and below, it would pass the CUSTOM type along silently and AWS CFn would allow it.
As of v2.6.0 they added JSON-Schema validation of the type that doesn’t include CUSTOM
as a valid option.
But looking at the docs you linked and the fact that it’s just a warning, it seems to be an incorrect warning.
Does the service still deploy event with the warning?
@bfieber yes, the service is deployed even with the warnging.