Saltar al contenido

Configuración del autorizador de Lambda compartido en Serverless Framework

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.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)


Tags :

Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *