Ошибка AWS Cognito Authorizer 500 Ошибка выполнения из-за внутренней ошибки - нулевое значение в заявке JWT - PullRequest
Новая
       31

Ошибка AWS Cognito Authorizer 500 Ошибка выполнения из-за внутренней ошибки - нулевое значение в заявке JWT

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

У меня проблема с авторизатором Cognito, и у меня закончились варианты тестирования (о которых я только могу подумать), поэтому мне стало интересно, сталкивался ли кто-либо с подобными проблемами.Я искал на форумах, и предыдущие случаи, похоже, были связаны с инцидентом AWS и "решили сами".Моя проблема продолжается уже более недели.

У меня есть 3 пользовательских пула Cognito, созданных с использованием Terraform (извините, Cloud Formation) и подключенных к различным API REST в качестве авторизаторов Cognito в API Gateway.У меня есть еще 3, почти идентичные (за исключением имен), прикрепленные к другим 3 API.

Если я возьму действительный JWT, полученный с помощью AWS Amplify (или непосредственно с помощью Cognito API), и либо протестирую авторизаторИспользуя консоль, протестировав авторизатор с помощью CLI или сделав запрос API к конечной точке с включенной аутентификацией, я получаю следующее: 

{
    "clientStatus": 500,
    "log": "Execution failed due to an internal error",
    "latency": 28
}

Я включил вход в систему API Gateway, и он мало что даетпонимание: 

00:17:50 (63aac040-e610-11e8-a304-1dab6e773ddd) Extended Request Id: QOP7MG0ELPEFUBg=
00:17:50 (63aac040-e610-11e8-a304-1dab6e773ddd) Starting authorizer: x1rebc for request: 63aac040-e610-11e8-a304-1dab6e773ddd
00:17:50 (63aac040-e610-11e8-a304-1dab6e773ddd) Execution failed due to an internal error
00:17:50 (63aac040-e610-11e8-a304-1dab6e773ddd) Gateway response type: DEFAULT_5XX with status code: 500
00:17:50 (63aac040-e610-11e8-a304-1dab6e773ddd) Gateway response body: {"message":null}
00:17:50 (63aac040-e610-11e8-a304-1dab6e773ddd) Gateway response headers: {Access-Control-Allow-Origin=*, Access-Control-Allow-Headers=Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token, Access-Control-Allow-Methods=GET,OPTIONS}

Если я скопирую сценарий Terraform и разверну другой пул пользователей и авторизатор, затем присоединю его к конечной точке сломанного API, тогда все в порядке.Если я присоединяю одного из трех других авторизаторов, которые уже развернуты к конечной точке сломанного API, все в порядке.

Если я присоединяю авторизатор из сломанной конечной точки к другой конечной точке API, которая работает и имеет аутентификациювключается (в другом API, который работает с работающим авторизатором), затем эта конечная точка API ломается ... так что это наводит меня на мысль, что это проблема Cognito, и я не могу получить никаких журналов!

Если бы это был почти любой другой ресурс AWS, я бы его скопировал, развернул и снова начал.Тем не менее, понимание первопричины этого очень важно для меня, так как объединение рабочего пула пользователей и всех пользователей и их данных, которые нельзя экспортировать или перенести (насколько я знаю), и перенастройка веб-приложения дляиспользовать новые идентификаторы приложений и пользовательских пулов Cognito, которые не могут быть статически сопоставлены (насколько я знаю), я не хочу рисковать в производственной среде.

Любая дополнительная информация или указатели были бы оченьоценили!Спасибо,

Том

1 Ответ

0 голосов
/ 25 апреля 2019

Если кто-то сталкивался с этим, я только что дошел до сути проблемы (обойдя ее несколько месяцев назад).

Я создавал заявку JWT с нулевым значением в триггере предварительного генерирования токена.Например,

{ "field": null }

Cognito в порядке с этим и отправляет токен обратно при входе в систему с этим нулевым значением.Однако, когда вы используете его для входа в систему, он падает и выдает загадочную «внутреннюю ошибку» без подробностей.

Изменение на следующее устраняет проблему:

{ "field" "null" }

...