serverless-heaven / serverless-aws-alias

Alias support for Serverless 1.x
MIT License
189 stars 68 forks source link

Support custom authorizers #22

Closed HyperBrain closed 7 years ago

HyperBrain commented 7 years ago

Custom authorizers should also be supported by the plugin, i.e. if a service defines custom authorizers, they have to be assigned to the correct stage and either the referenced alias lambda has to be set as target or, in case a full qualified arn has been given, this has to be set.

21 Is caused by the missing feature.

andrewkuzmych commented 7 years ago

+1

HyperBrain commented 7 years ago

The referenced lambda function has to be completed with the alias stage variable - myAuth-func:${stageVariables.SERVERLESS_ALIAS} This will work in the first place. It has to be checked, if deployments from different aliases with changed authorizer configurations (like header spec etc.) will cause unwanted behaviors. Otherwise the authorizer should be renamed by the plugin and deployed separately per alias.

HyperBrain commented 7 years ago

Authorizers do not support APIG stage variables. The authorizer is renamed to include the deployed alias and points to the correct aliased function version. Verified the functionality with a test project and by creating a Swagger definition of the deployed stage from the AWS APIG console.

HyperBrain commented 7 years ago

@vkkis93 Could you try if it works for you? Then I will prepare the 1.2.0 release tomorrow.

vkkis93 commented 7 years ago

@HyperBrain Why previous serverless@0.5 for example has correct authorizer function it has func:${stageVariables.functionAlias} I don't understand why we can not set func:${stageVariables.SERVERLESS_ALIAS}

HyperBrain commented 7 years ago

Ok. I will check how exactly the 0.5 version created the authorizer - I'll try to use the same parameters then and see if it works.

vkkis93 commented 7 years ago

Can we do like this ? uriParts.splice(funcIndex + 1, 0, '${stageVariables.SERVERLESS_ALIAS}');

HyperBrain commented 7 years ago

Can you try this locally and check if the deployment works with the API console and a deployed API? If it works, I have no objections against this solution.