serverless-aws-alias
serverless-aws-alias copied to clipboard
serverless-heaven
Alias Authorizers
When deploying an alias I have noticed that the old authorizers defined in API gateway are removed and a new set of authorizers are created that includes the alias name. I was wondering if this was intended behavior as I would think the authorizers could always have the same name, but then the stage vars on the authorizer definition would be leveraged so that the correct version was executed.
It is intended behavior, because the authorizer name must be unique, and a different alias can define the authorizer with different settings (not only a different target). E.g. you can change the type of an authorizer to "REQUEST" instead of "TOKEN" in your development branch and deploy your branch as alias.
Having only the stage vars approach would force the authorizer definition itself the same on all aliases and any deploy will have an effect on all other already deployed aliases. As far as I know authorizers are not even deployed to a stage within APIG but stay globally cross stage there (but I might be wrong).
Thanks for the clarification and I believe you are correct on the authorizers being cross stage. The authorizer name is referenced on the base resource definition in APIG so when you deploy an alias it looks like all existing aliases are now using the new alias authorizer definitions.
If authorizers are cross-stage, might that be a reason to maintain the original authorizer names? Renaming them to include the authorizer name made me think that these authorizers were specific to the stage / alias, which doesn't appear to be possible in APIG.
The renaming is on purpose because authorizer X can be deployed to alias A1 with a different configuration than in alias A2.
Imagine that you have a stable alias that contains the stable deployment. Then you have developer A who rewrites the authorizer and applies a different configuration (like changing TOKEN to REQUEST or changing the internal validation). Now the developer deploys it to his own alias (e.g. feature-1).
If the name would not be changed by the plugin, the developer would just screw the stable deployment because the authorizer will be replaced.
The isolation that the plugin offers can only work properly if APIG global resources (stage independent) are renamed automatically. The plugin aims to overcome the APIG behavior and provide an isolation in the best way possible.
I don't think I understand how one would deploy two authorizers with different configurations with this plugin. In my experience, deploying an alias overwrites the existing authorizers to contain the alias name. I agree that having separate copies would be useful if that's possible.
My experience is the same as @BrandonEvansAsurion in that the authorizers are overwritten when deploying an alias as opposed to creating new ones. Based on what you are describing above I am assuming that is not intended behavior?
@zachboyd Yes. They should be separate per alias deployment. I remember that I implemented it that way, but there might be a bug. I'll have to check.
Thanks. Based on what you find I don't mind helping fix the issue if it does happen to be a bug. Just want to better understand the intended behavior as I haven't dug into authorizers a whole lot.
Hello @HyperBrain @zachboyd any updates on this ? On my side the aliases seems to work (when i hit a stage i reach the associated authorizer) but they doesn't appear inside API Gateway console on AWS, they seems to be deleted.
