API-шлюз возвращает 401 и не вызывает пользовательский авторизатор - PullRequest
Новая
       6

API-шлюз возвращает 401 и не вызывает пользовательский авторизатор

1 голос
/ 06 января 2020

Я реализовал собственный авторизатор типа «ЗАПРОС» для шлюза API, который проверяет токен JWT, переданный в заголовке «Авторизация». Я протестировал лямбду самостоятельно, и она работает как положено. Я также подключил авторизатор к своим маршрутам и могу протестировать его в консоли AWS - опять все работает (см. Изображение):

успешный вызов через консоль

Однако, когда я пытаюсь вызвать свои конечные точки с токеном в заголовке Authorization, я всегда получаю НЕСАНКЦИОНИРОВАННЫЙ ответ: 

{
  "errors": [
    {
      "category": "ClientError",
      "code": "UNAUTHORIZED",
      "detail": "Unauthorized",
      "method": "GET",
      "path": "/cases",
      "requestId": "004eb254-a926-45ad-96a5-ce3527621c81",
      "retryable": false
    }
  ]
}

Из того, что я собрал, шлюз API никогда не вызывает Мой Авторизатор, поскольку я не вижу никаких событий журнала в его облачных часах. Мне удалось включить ведение журнала в облачном хранилище моего шлюза API, и единственная информация о журнале, которую я вижу, такова: 

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|   timestamp   |                                                                                                                             message                                                                                                                              |
|---------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 1578275720543 | (dac0d4f6-1380-4049-bcee-bf776ca78e5c) Extended Request Id: F2v9WFfiIAMF-9w=                                                                                                                                                                                     |
| 1578275720543 | (dac0d4f6-1380-4049-bcee-bf776ca78e5c) Unauthorized request: dac0d4f6-1380-4049-bcee-bf776ca78e5c                                                                                                                                                                |
| 1578275720543 | (dac0d4f6-1380-4049-bcee-bf776ca78e5c) Extended Request Id: F2v9WFfiIAMF-9w=                                                                                                                                                                                     |
| 1578275720544 | (dac0d4f6-1380-4049-bcee-bf776ca78e5c) Gateway response type: UNAUTHORIZED with status code: 401                                                                                                                                                                 |
| 1578275720544 | (dac0d4f6-1380-4049-bcee-bf776ca78e5c) Gateway response body: {"errors": [{"category": "ClientError","code": "UNAUTHORIZED","detail": "Unauthorized","method": "GET","path": "/cases","requestId": "dac0d4f6-1380-4049-bcee-bf776ca78e5c","retryable": false }]} |
| 1578275720544 | (dac0d4f6-1380-4049-bcee-bf776ca78e5c) Gateway response headers: {}                                                                                                                                                                                              |
| 1578275720544 | (dac0d4f6-1380-4049-bcee-bf776ca78e5c) Gateway response type: UNAUTHORIZED with status code: 401                                                                                                                                                                 |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

На данный момент я полностью застрял и не уверен, как отлаживать это дальше. Я предполагаю, что что-то должно быть настроено неправильно, но информация журнала, которую я могу найти, не дает никаких указаний на проблему. Я также вставил копию своей конфигурации авторизаторов на изображении ниже:

Конфигурация авторизатора

Снимок экрана одной конечной точки, настроенной для использования авторизатора

1 Ответ

0 голосов
/ 06 января 2020

Я выяснил проблему, с которой столкнулся: мне нужно было установить identitySource: method.request.header.Authorization в поле авторизатора конечной точки, а также в стеке CF.

Определение пользовательского авторизатора в raw cloudformation: 

service: 
  name: api-base

frameworkVersion: ">=1.2.0 <2.0.0"

plugins:
  - serverless-plugin-optimize
  - serverless-offline
  - serverless-pseudo-parameters
  - serverless-domain-manager

custom:
  stage: ${self:provider.stage, 'dev'}
  serverless-offline:
    port: ${env:OFFLINE_PORT, '4000'}
  false: false
  cognitoStack: marley-auth
  customDomain:
    domainName: ${env:BE_HOST, ''}
    enabled: ${env:EN_CUSTOM_DOMAIN, self:custom.false}
    stage: ${self:provider.stage, 'dev'}
    createRoute53Record: true

provider:
  name: aws
  runtime: nodejs10.x
  versionFunctions: true
  apiName: public
  logs:
    restApi: true
  stackTags:
      COMMIT_SHA: ${env:COMMIT_SHA, 'NO-SHA'}
  environment:
    USER_POOL_ID: ${cf:${self:custom.cognitoStack}-${self:custom.stage}.UserPoolId}
    CLIENT_ID: ${cf:${self:custom.cognitoStack}-${self:custom.stage}.UserPoolClientId}
  timeout: 30
  iamRoleStatements:
  - Effect: "Allow"
    Action:
      - "lambda:InvokeFunction"
    Resource: "*"

functions:
  authorizer:
    handler: handler/authorize.handler

resources:
  - Outputs:
      ApiGatewayRestApiId:
        Value:
          Ref: ApiGatewayRestApi
        Export:
          Name: ${self:custom.stage}-${self:provider.apiName}-ApiGatewayRestApiId
      ApiGatewayRestApiRootResourceId:
        Value:
          Fn::GetAtt:
            - ApiGatewayRestApi
            - RootResourceId 
        Export:
          Name: ${self:custom.stage}-${self:provider.apiName}-ApiGatewayRestApiRootResourceId
      SharedAuthorizerId:
        Value:
          Ref: SharedAuthorizer
        Export:
          Name: ${self:custom.stage}-${self:provider.apiName}-ApiGatewaySharedAuthorizerId
  - Resources:
      SharedAuthorizer:
        Type: AWS::ApiGateway::Authorizer
        Properties:
          Name: public
          AuthorizerUri: !Join 
            - ''
            - - 'arn:aws:apigateway:'
              - !Ref 'AWS::Region'
              - ':lambda:path/2015-03-31/functions/'
              - !GetAtt 
                - AuthorizerLambdaFunction
                - Arn
              - /invocations
          RestApiId: !Ref 'ApiGatewayRestApi'
          Type: REQUEST
          IdentitySource: method.request.header.Authorization
          AuthorizerResultTtlInSeconds: '300'
        DependsOn: AuthorizerLambdaFunction
      ApiAuthLambdaPermission:
        Type: AWS::Lambda::Permission
        Properties:
          Action: lambda:InvokeFunction
          FunctionName: !Ref AuthorizerLambdaFunction
          Principal: apigateway.amazonaws.com
          SourceArn: !Sub "arn:aws:execute-api:#{AWS::Region}:#{AWS::AccountId}:#{ApiGatewayRestApi}/authorizers/*"
        DependsOn: ApiGatewayRestApi

Использование авторизатора в другом стеке - обратите внимание, что я указал IdentitySource здесь, а также в определении авторизатора - по какой-то причине мне пришлось сделать это в обоих местах. 

authorizer:
  type: CUSTOM
  authorizerId: ${cf:api-base-${self:custom.stage}.SharedAuthorizerId}
  identitySource: method.request.header.Authorization
...