serverless-aws-alias icon indicating copy to clipboard operation
serverless-aws-alias copied to clipboard

Cannot use Authorizer ARN

Open mwillfox opened this issue 6 years ago • 11 comments

I'm having an issue where I'm attempting to use an ARN for my authorizer (all of my services share a common authorizer) but the plugin is inserting ${stageVariables.SERVERLESS_ALIAS} where it does not belong, in front of the ARN. Is this a bug or do I need to do something special in the yaml to tell serverless-aws-alias to not attempt to modify the ARN? I believe the preferred behavior would be if an ARN was provided for the authorizer to pass it through unmodified because it exists outside of this stack.

mwillfox avatar Mar 14 '18 18:03 mwillfox

Hi @defendertx , yes you're right. External references should not be altered but just used as is.

I recently merged PR #102 and think that addresses exactly your problem. Can you try with the master branch of the project and confirm that it works for you?

"serverless-aws-alias": "github:HyperBrain/serverless-aws-alias#master"

HyperBrain avatar Mar 14 '18 18:03 HyperBrain

Master works as expected. Thanks!

mwillfox avatar Mar 14 '18 19:03 mwillfox

Good to know. I'll do a release soon.

HyperBrain avatar Mar 14 '18 19:03 HyperBrain

I've tried master to avoid this issue, and have not had any success as yet.

my authorizer arn is serverless custom var, in turn is a collections of serverless vars forming a string, some of which are ${cf.:authorizer-arn} type vars. Im wondering if its the cf import that may be throughing this off.

ColeTMNZ avatar Mar 15 '18 03:03 ColeTMNZ

@ColeTMNZ The CF resolution in Serverless should resolve before the alias plugin is used. But could you do a serverless package and check in the generated .serverless/cloudformation......json if the arn in the function/permission resources is the expected arn?

HyperBrain avatar Mar 15 '18 09:03 HyperBrain

Heres my authorizer resource. Is it possibly the join that's throwing errors?

"AuthorizerApiGatewayAuthorizer": {
      "Type": "AWS::ApiGateway::Authorizer",
      "Properties": {
        "AuthorizerResultTtlInSeconds": 0,
        "IdentitySource": "method.request.header.x-tmnz-api-key",
        "Name": "authorizer",
        "RestApiId": {
          "Ref": "ApiGatewayRestApi"
        },
        "IdentityValidationExpression": ".*",
        "AuthorizerUri": {
          "Fn::Join": [
            "",
            [
              "arn:aws:apigateway:",
              {
                "Ref": "AWS::Region"
              },
              ":lambda:path/2015-03-31/functions/",
              {
                "Fn::Sub": "arn:aws:lambda:${AWS::Region}:xxyyzz:function:authorizer-service-dev-authorizer"
              },
              "/invocations"
            ]
          ]
        },
        "Type": "TOKEN"
      }
    },

ColeTMNZ avatar Mar 15 '18 09:03 ColeTMNZ

@ColeTMNZ Yes it is. I think we have to improve the detection algorithm for external authorizers, because right now it seems to miss this case.

HyperBrain avatar Mar 15 '18 09:03 HyperBrain

I think this is the same issue I raise in #112. Should be fixed with #113

aleksdikanski avatar Mar 20 '18 20:03 aleksdikanski

@ColeTMNZ Can you try with the master branch if the issue is solved. I just merged #113 .

If it solved your problem, I'll close this one and will release 1.6.2.

HyperBrain avatar Mar 20 '18 20:03 HyperBrain

I believe I confirmed this worked. My stack gets a lot further in the creation process, and fails on other unrelated issues now. (alias & domain manager, alias and step functions)

I checked the cloud formation template and the Authorizer Resources were correctly created. (before being removed due to other mentioned errors)

ColeTMNZ avatar Mar 21 '18 22:03 ColeTMNZ

I'll target this for 1.7+.

HyperBrain avatar Apr 20 '18 11:04 HyperBrain