AWS API Gateway Custom Authorizer странно показывает ошибку - PullRequest
Новая
       49

AWS API Gateway Custom Authorizer странно показывает ошибку

0 голосов
/ 14 мая 2018

Вот контекст:

  • Я настроил ресурс в шлюзе API./ пользователь / компания
  • Этот ресурс имеет 2 метода.Get и POST.
  • Я настроил собственный авторизатор для этого ресурса.

Проблема:

  • Я могу вызвать метод GET, отправив праваавторизации и я получаю результаты, как и ожидалось.
  • Я пытаюсь отправить запрос POST и получаю следующую ошибку: 

{
  "message": "User is not authorized to access this resource"
}
  • Если я подожду несколько минут, затем вызову метод POST, он будет работать.
  • Если после вызова метода POST и полученияРезультаты я вызываю метод GET, он будет отображать ту же ошибку, что и выше.

Кроме того, я отключил кеш для авторизатора.

enter image description here

Что могло вызвать эту проблему?

Ответы [ 3 ]

0 голосов
/ 20 марта 2019

При использовании пользовательского кода сборки политики модуль js узла aws-auth-policy Часть Nodejs, которую вы можете использовать, 

AuthPolicy.prototype.allowAllMethods = function () {
  addMethod.call(this, "allow", "*", "*", null);
}

В коде 

const AuthPolicy = require('aws-auth-policy');
  const policy = new AuthPolicy(principalId, awsAccountId, apiOptions);
           // policy.allowMethod(method, resource);
            policy.allowAllMethods();
            const authResponse = policy.build();
0 голосов
/ 13 мая 2019

Эта ошибка возникает, если вы используете event.methodArn в качестве ресурса для сгенерированной политики и совместно используете авторизатор между различными функциями из-за того, как работает кэширование политики. Для предоставленного токена он кэширует политику по всему API, это будет одна и та же запись кэша для всех методов и ресурсов в одном и том же API и этапе (если они совместно используют один и тот же авторизатор).

Например, при отправке запроса на GET /users ARN будет выглядеть примерно так: 

arn:aws:execute-api:us-1:abc:123/prod/GET/users

При следующем вызове любой конечной точки с таким же токеном аутентификации будет использоваться кэшированная политика, которая была создана при первом вызове GET /users. Проблема с этой кэшированной политикой заключается в том, что ее ресурс допускает только один конкретный ресурс arn: ... /prod/GET/users, любой другой ресурс будет отклонен.

В зависимости от того, насколько вы хотите ограничить разрешения политики, вы можете указать любой возможный ресурс при создании политики 

{
  "principalId": "user",
  "policyDocument": {
    "Statement": [
      {
        "Action": "execute-api:Invoke",
        "Effect": "Allow",
        "Resource": [
          "arn:aws:execute-api:us-1:abc:123/prod/GET/v1/users",
          "arn:aws:execute-api:us-1:abc:123/prod/POST/v1/users",
          "arn:aws:execute-api:us-1:abc:123/prod/GET/v1/orders"
        ]
      }
    ],
    "Version": "2012-10-17"
  }
}

или используйте подстановочные знаки 

"Resource": "arn:aws:execute-api:us-1:abc:123/prod/*/v?/*"

или даже 

"Resource": "*"

Вы можете использовать переменные политики для некоторых расширенных шаблонов.

Можно также использовать подход черного списка, разрешив все с использованием подстановочных знаков, а затем запретив определенные ресурсы в другом выражении политики.

Источники:

0 голосов
/ 01 ноября 2018

Это можно исправить с помощью двух опций, описанных в ответе багги: https://forum.serverless.com/t/rest-api-with-custom-authorizer-how-are-you-dealing-with-authorization-and-policy-cache/3310

Короткая версия:

  1. Установите TTL для авторизатора клиента на 0
  2. Установить пользовательский ресурс политики авторизатора как "*"

Попробовал оба решения, и они решили проблему с "Пользователь не авторизован для доступа к этому ресурсу" для меня.

...