Error "Event references not configured authorizer 'name'" when following authorizer tutorial

[BryanCrotaz]

Completely failed to work out how to add authorizers to my httpAPI, so trying every example you have.

Followed https://www.serverless.com/framework/docs/providers/aws/events/apigateway#http-endpoints-with-custom-authorizers

I think although this is an http event it's actually a RESTApi?

Get an error Event references not configured authorizer '<function-name>' and I can't find any reference to this in the docs. Don't know what event I should be adding to the authorizer function as the examples don't list any events.

serverless.yml

provider:
  name: aws
  runtime: dotnetcore2.1

  stage: dev
  region: us-east-1

  apiGateway:
    minimumCompressionSize: 1024

  httpApi:
    cors: true
    payload: "2.0"
    
package:
  individually: true

functions:

  apiAuthorizer:
    handler: AuthApi::AuthApi.AuthHandlers::Authorize
    package:
      include:
        - AuthApi/AuthApi.csproj
    iamRoleStatements:
      - Effect: Allow # note that these rights are given in the default policy and are required if you want logs out of your lambda(s)
        Action:
        - logs:CreateLogGroup
        - logs:CreateLogStream
        - logs:PutLogEvents
        Resource:
        - 'Fn::Join':
            - ':'
            -
                - 'arn:aws:logs'
                - Ref: 'AWS::Region'
                - Ref: 'AWS::AccountId'
                - 'log-group:/aws/lambda/*:*:*'

  get-metric-history:
    handler: DashboardApi::DashboardApi.HistoryHandlers::GetMetricHistory
    environment:
      DeviceMetricsTable: 
        Ref: DeviceMetricsTable
    events:
      - http: 
          path: metrics/history
          method: get
          cors: true
          authorizer: apiAuthorizer
    package:
      include:
        - DashboardApi/DashboardApi.csproj
    iamRoleStatements:
      - Effect: "Allow"
        Action:
          - dynamodb:Query
        Resource:
          Fn::GetAtt:
            - DeviceMetricsTable
            - Arn
      - Effect: Allow # note that these rights are given in the default policy and are required if you want logs out of your lambda(s)
        Action:
        - logs:CreateLogGroup
        - logs:CreateLogStream
        - logs:PutLogEvents
        Resource:
        - 'Fn::Join':
            - ':'
            -
                - 'arn:aws:logs'
                - Ref: 'AWS::Region'
                - Ref: 'AWS::AccountId'
                - 'log-group:/aws/lambda/*:*:*'

sls deploy output

Installed version

C:\projects\led-monitor>serverless --version
Serverless: Running "serverless" installed locally (in service node_modules)
Framework Core: 1.77.1
Plugin: 3.6.18
SDK: 2.3.1
Components: 2.33.2

[pgrzesik]

Hello @BryanCrotaz, thanks for reporting, before treating it as a bug, could you please upgrade to the latest version of Framework (we're currently on 2.19.0 where you're on 1.77.1) to ensure that the issue wasn't fixed in the meantime?

[BryanCrotaz]

I'm using my fork #8043 as .net isn't supported by master, but I'll try to rebase it.

[BryanCrotaz]

No, same problem on master.

[BryanCrotaz]

My function definition:

  get-metric-history:
    handler: DashboardApi::DashboardApi.HistoryHandlers::GetMetricHistory
    environment:
      DeviceMetricsTable: 
        Ref: DeviceMetricsTable
    events:
      - httpApi: 
          path: metrics/history
          method: get
          authorizer: apiAuthorizer
    package:
      include:
        - DashboardApi/DashboardApi.csproj
    iamRoleStatements:
      - Effect: "Allow"
        Action:
          - dynamodb:Query
        Resource:
          Fn::GetAtt:
            - DeviceMetricsTable
            - Arn
      - Effect: Allow # note that these rights are given in the default policy and are required if you want logs out of your lambda(s)
        Action:
        - logs:CreateLogGroup
        - logs:CreateLogStream
        - logs:PutLogEvents
        Resource:
        - 'Fn::Join':
            - ':'
            -
                - 'arn:aws:logs'
                - Ref: 'AWS::Region'
                - Ref: 'AWS::AccountId'
                - 'log-group:/aws/lambda/*:*:*'

[BryanCrotaz]

Authorizer:

  apiAuthorizer:
    handler: AuthApi::AuthApi.AuthHandlers::Authorize
    package:
      include:
        - AuthApi/AuthApi.csproj
    iamRoleStatements:
      - Effect: Allow # note that these rights are given in the default policy and are required if you want logs out of your lambda(s)
        Action:
        - logs:CreateLogGroup
        - logs:CreateLogStream
        - logs:PutLogEvents
        Resource:
        - 'Fn::Join':
            - ':'
            -
                - 'arn:aws:logs'
                - Ref: 'AWS::Region'
                - Ref: 'AWS::AccountId'
                - 'log-group:/aws/lambda/*:*:*'

[BryanCrotaz]

Am I using it incorrectly?

[BryanCrotaz]

Worked it out, but error messages were not very helpful. Created a PR with more informative messages.

[pgrzesik]

Thanks for the update @BryanCrotaz - do you think we could close this issue then? As for supporting different types of authorizers for HTTP API, let's track that discussion here: #8210

[ed-sparkes]

#8210 seems to have been forgotten about, 5+ months after release of AWS functionality and hardly any activity on this, kinda takes the zero-friction out of the 'zero-friction serverless deployment'

[pgrzesik]

Hello @ed-sparkes - unfortunatelly, there were some other priorities in the meantime, but we plan to dedicate time to #8210 in the coming weeks. I'll follow up later this week on the original issue about authorizers. Sorry for inconvenience.

I'll close this issue and let's move all potential discussions to #8210

[astuyve]

👋🏻 Hi @pgrzesik ❤️
I noticed this issue today as I was setting up a demo. I received the same message using an HTTP API:

Naturally I tracked down this issue and #8210 where I found the correct syntax, but so many Serverless blog posts and references use the old style syntax. This led me to attempt this, which throws the above error (edited because my suggestion was mistaken and I'd prefer if other developers don't inadvertently try it!)

Would it be possible/would you accept a PR which creates a validation warning when a user uses this syntax? Is there another way this could prevent people from tripping up on "Event references not configured authorizer 'name'" while using HTTP APIs?

Thanks, hope you're well!

[pgrzesik]

Hello @astuyve 👋 Nice to see you here 🙌 I see how it might be tripping people up as httpApi and http have different way of setting up authorizers. If I understand correctly, you're suggesting to provide a more verbose error message when someone tries to use http-style authorizer instead of httpApi-one, correct? We'd be happy to have that PR in for sure 💯

btw, the example you've listed as working I believe is not correct, as the authorizers are defined on provider.httpApi level, not directly on events

[astuyve]

Hey Piotr! I removed my erroneous example to prevent others from erroneously copying it.

Yes, that'd be great! I'd love if the framework would provide an error message stating something like "http authorizer is not valid for httpApi" or something of that ilk. I do not believe this is a defect or flaw in the framework, just a reality of being downstream from AWS, and their offering of two VERY similar (but technically different) API products.

[pgrzesik]

Thanks for clarification, I'll see how we could incorporate such tip into our current error, thanks @astuyve 🙇