Bug in Api Gateway Authorizer schema for authorizer.type = CUSTOM?

Serverless Framework
#1

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:

#2

Hi

I am having the same warning, did you find how to remove it?

#3

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.
#4

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).
#5

@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.

#6

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?

#7

@bfieber yes, the service is deployed even with the warnging.