У меня была та же проблема, которую вы описали. Или, по крайней мере, я так думаю. И мне удалось решить эту проблему, следуя документации по предоставленным вами ссылкам.
В серверной документации указано, что формат авторизатора равен
authorizer:
# Provide both type and authorizerId
type: COGNITO_USER_POOLS # TOKEN or COGNITO_USER_POOLS, same as AWS Cloudformation documentation
authorizerId:
Ref: ApiGatewayAuthorizer # or hard-code Authorizer ID
Насколько я понимаю, мое решение (приведено ниже) следует жестко закодированному идентификатору авторизатора.
В службе, имеющей общий авторизатор, он объявлен в serverless.yml обычным образом, т.е.
functions:
myCustomAuthorizer:
handler: path/to/authorizer.handler
name: my-shared-custom-authorizer
Затем в службе, которая хочет использовать этот общий авторизатор, функция в servlerless.yml объявлена как
functions:
foo:
# some properties ...
events:
- http:
# ... other properties ...
authorizer:
name: authorize
arn:
Fn::Join:
- ""
- - "arn:aws:lambda"
# References to values such as region, account id, stage, etc
# Can be done with Pseudo Parameter Reference
- ":"
- "function:myCustomAuthorizer"
Важно было добавить свойство name. Без него ничего бы не получилось, по крайней мере, на данный момент.
Подробнее см.
К сожалению, я не могу сказать, имеет ли этот подход некоторые ограничения по сравнению с вашим предложением об определении авторизатора в качестве ресурса. Фактически, это может упростить повторное использование одного и того же авторизатора в нескольких функциях в пределах одной службы.