Custom authorizer support. Authorizer URIs point to the aliased function version and the authorizer name is appended with the alias name.
The authorizer will be deployed into the APIG stage. If a different alias is deployed that does not contain an authorizer, it will disappear from the API staging area (console), but remains deployed within the correct stage. This is expected behavior, because an APIG deployment to a stage will deploy the complete staging area - so everything not part of the current deployment has to be removed.
From a functional perspective the deployed APIs remain completely intact.
Coverage decreased (-0.4%) to 51.651% when pulling 06bbfedfa11a6b0171b881565f8327e4adb85f8a on support-custom-authorizers into f7ca6081fe9fcab3e80f87e337c961922d53476a on master.
Coverage decreased (-0.4%) to 51.651% when pulling 5756f32ef8223592e73741cec590ed9793590989 on support-custom-authorizers into f7ca6081fe9fcab3e80f87e337c961922d53476a on master.
Closes #22
Custom authorizer support. Authorizer URIs point to the aliased function version and the authorizer name is appended with the alias name.
The authorizer will be deployed into the APIG stage. If a different alias is deployed that does not contain an authorizer, it will disappear from the API staging area (console), but remains deployed within the correct stage. This is expected behavior, because an APIG deployment to a stage will deploy the complete staging area - so everything not part of the current deployment has to be removed. From a functional perspective the deployed APIs remain completely intact.