Presta atención porque en este artículo hallarás el arreglo que buscas.
EDITAR: Aparentemente, mi respuesta ahora está desactualizada. Para obtener versiones más recientes de servicestack, consulte las otras respuestas. No sé cuál es la mejor respuesta / la más actualizada, pero si alguien me avisa, cambiaré la respuesta aceptada por esa.
Finalmente logré que funcionara, así que así es como configuré serverless.yml de mi autorizador:
service: user-admin-authorizer
custom:
region: $file(serverless.env.yml):$opt:stage.REGION
provider:
name: aws
region: $self:custom.region
functions:
authorizer:
handler: src/authorizer.handler
runtime: nodejs8.10
resources:
Resources:
Authorizer:
Type: AWS::ApiGateway::Authorizer
Properties:
Name: Authorizer
Type: REQUEST
AuthorizerUri:
Fn::Join: [ "",
[
"arn:aws:apigateway:",
"$self:custom.region",
":lambda:path/",
"2015-03-31/functions/",
Fn::GetAtt: ["AuthorizerLambdaFunction", "Arn" ],
"/invocations"
]]
RestApiId:
Fn::ImportValue: api-gateway:$opt:stage:rest-api-id
apiGatewayLambdaPermissions:
Type: AWS::Lambda::Permission
Properties:
FunctionName:
Fn::GetAtt: [ AuthorizerLambdaFunction, Arn]
Action: lambda:InvokeFunction
Principal:
Fn::Join: [ "",
[
"apigateway.",
Ref: AWS::URLSuffix
]]
Outputs:
AuthorizerRef:
Value:
Ref: Authorizer
Export:
Name: authorizer-ref:$opt:stage
Cosas a tener en cuenta: aunque la función del autorizador se llama “autorizador”, debe escribir en mayúscula la primera letra y agregar “LambdaFunction” a su nombre cuando se usa con GetAtt, por lo que “autorizador” se convierte en “AuthorizerLambdaFunction” por alguna razón. También tuve que agregar el recurso de permiso lambda.
El recurso de puerta de enlace de API también necesita dos salidas, su ID de API y su ID de recurso raíz de API. Así es como se configura serverless.yml de mi puerta de enlace API:
resources:
Resources:
ApiGateway:
Type: AWS::ApiGateway::RestApi
Properties:
Name: ApiGateway
Outputs:
ApiGatewayRestApiId:
Value:
Ref: ApiGateway
Export:
Name: api-gateway:$opt:stage:rest-api-id
ApiGatewayRestApiRootResourceId:
Value:
Fn::GetAtt:
- ApiGateway
- RootResourceId
Export:
Name: api-gateway:$opt:stage:root-resource-id
Ahora solo necesita especificar a sus otros servicios que deben usar esta puerta de enlace API (los valores importados son las salidas de la puerta de enlace API):
provider:
name: aws
apiGateway:
restApiId:
Fn::ImportValue: api-gateway:$opt:stage:rest-api-id
restApiRootResourceId:
Fn::ImportValue: api-gateway:$opt:stage:root-resource-id
Después de eso, el autorizador se puede agregar a funciones individuales en este servicio de la siguiente manera:
authorizer:
type: CUSTOM
authorizerId:
Fn::ImportValue: authorizer-ref:$opt:stage
Tuve el mismo problema que usted describe. O al menos eso creo. Y logré resolverlo siguiendo la documentación sobre los enlaces que proporcionó.
La documentación sin servidor indica que el formato del autorizador es
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
Según tengo entendido, mi solución (proporcionar a continuación) sigue el enfoque de ID de autorizador codificado de forma rígida.
En el servicio que tiene el autorizador compartido, se declara en serverless.yml de manera normal, es decir
functions:
myCustomAuthorizer:
handler: path/to/authorizer.handler
name: my-shared-custom-authorizer
Luego, en el servicio que desea usar este autorizador compartido, la función en servlerless.yml se declara como
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"
Era crucial agregar la propiedad del nombre. No funcionaría sin él, al menos por el momento.
Para obtener más detalles, consulte
- Convenciones de nomenclatura ARN
- Referencia de pseudoparámetros
- Fn :: Únete
Desafortunadamente, no puedo decir si este enfoque tiene algunas limitaciones en comparación con su sugerencia de definir al autorizador como un recurso. De hecho, eso podría facilitar la reutilización del mismo autorizador en varias funciones dentro del mismo servicio.
Te mostramos las comentarios y valoraciones de los usuarios
Al final de todo puedes encontrar las explicaciones de otros desarrolladores, tú asimismo tienes el poder dejar el tuyo si lo crees conveniente.