serverless-aws-alias
serverless-aws-alias copied to clipboard
Cannot use Authorizer ARN
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.
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"
Master works as expected. Thanks!
Good to know. I'll do a release soon.
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.
@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?
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 Yes it is. I think we have to improve the detection algorithm for external authorizers, because right now it seems to miss this case.
I think this is the same issue I raise in #112. Should be fixed with #113
@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.
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)
I'll target this for 1.7+.