Блог

Главная - Вопросы по программированию - Тестирование REST API и сервера идентификации 4 с Postman

Тестирование REST API и сервера идентификации 4 с Postman

#api #rest #authentication #postman #identityserver4

#API #rest #аутентификация #postman #identityserver4

Вопрос:

У меня есть решение, в котором есть мое веб-приложение, мой REST API и мой сервер идентификации 4. Все они теперь находятся на .net 5. Локально все работает нормально, но как только я загружаю все на сервер, я получаю сообщение об ошибке Postman.

Настройка — API и сервер IDP находятся на разных сайтах.

Что я знаю — я знаю, что сервер IDP работает, потому что я могу получить токен в Postman. Я также знаю, что фактический API работает, потому что, когда я удаляю атрибут [Authorize] с имеющегося у меня контроллера, вызов Postman работает нормально.

Проблема — проблема, с которой я сталкиваюсь сейчас, заключается в том, что когда я возвращаю атрибут [Authorize], я всегда получаю несанкционированную ошибку 401 для вызова API. Ниже приведена часть файла запуска, которая настраивает аутентификацию:

 services.AddAuthentication(IdentityServerAuthenticationDefaults.AuthenticationScheme)
                .AddIdentityServerAuthentication(options =>
                {
                    options.Authority = "https://bob.com/API-IDP/";
                    options.ApiName = "BOBSAPI";
                    options.ApiSecret = "bobssecret";
                });

Я также знаю, что часть Configure, что порядок использования ***** правильный. Я также попытался настроить настройки AppPool с точки зрения «Профиля загрузки», все на основе того, что я нашел во время поиска. Я перешел на веб-сайт Identity 4 и следовал этим примерам как можно лучше. О, еще одна вещь. В базе данных IDP есть таблица для постоянных грантов. Я вижу несколько записей в этой таблице, что, я думаю, означает, что аутентификация сработала? Но если аутентификация сработала, то почему вызов API вернул 401? Есть ли что-то, что мне нужно сделать на контроллере, кроме атрибута [Authorization]? Я потратил на это 3 дня, и я рву на себе волосы. Пожалуйста, помогите!

Ответ №1:

Я бы посмотрел на заголовки ответов ответа от API и посмотрел, дает ли этот заголовок какие-либо подсказки о том, почему вы не авторизованы:

Например:

 HTTP/1.1 401 Unauthorized
Date: Sun, 02 Aug 2020 11:19:06 GMT
WWW-Authenticate: Bearer error="invalid_token", error_description="The signature is invalid"

Вы также должны убедиться, что для этого флага установлено значение True в конфигурации AddJwtBearer:

 //True if token validation errors should be returned to the caller.
options.IncludeErrorDetails = true;

Для этого вы можете использовать такой инструмент, как Fiddler.

Тогда я бы посмотрел на ASP.NET Основной файл журнала, чтобы определить, почему он не принимает ваш токен.

Комментарии:

1. Спасибо за это. Я загрузил Fiddler, и заголовок ответа вообще не содержит ничего раскрывающего. В заголовках запроса я вижу, что токен-носитель присутствует, и он правильный. Если я посмотрю на вкладку Auth запроса, там будет правильный заголовок. Кроме того, у меня нет возможности IncludeErrorDetails в конфигурации IdentityServer.

2. Я не знаю, имеет ли это значение или нет, но у нас настроен сервер как example.com , с рядом веб-сайтов под ним. Итак, API — это приложение под example.com/API . И сервер идентификации настроен как приложение под example.com/IDP . Не должно иметь значения, что это не корневой сайт, не так ли?

3. Как вы защищаете API? обычно вы используете AddJwtBearer для защиты API, а затем получаете этот заголовок, как я писал ранее. Кроме того, я обычно рекомендую размещать IdentiyServer, ваш клиент и API в разных доменах служб, просто чтобы лучше понимать, когда это не работает. Когда все это смешивается вместе, устранение неполадок становится проблемой. затем я бы увеличил уровень журнала и посмотрел на необработанные журналы.

4. Файлы cookie могут быть проблемой, если для них установлен атрибут path attribute . Проверьте, как установлены файлы cookie. затем я бы удалил атрибут авторизации и поставил точку останова в методе действия и посмотрел, есть ли у меня вообще пользователь в HttpContext. Пользовательский объект

5. Хорошо, вопрос к вам. Для AddJwtBearer, о котором вы говорите в файле установки? Я пробовал это раньше, и это не сработало. Однако я тоже не смотрел на заголовки ответов, когда делал это, поэтому я попробую еще раз. Я знаю, что API работает, когда атрибут авторизации удален, но я не думал о проверке пользователя. Хорошая идея! Я тоже попробую. Спасибо!

Ответ №2:

Это заняло немного времени, но с некоторой помощью от Tore Nestenius я смог разобраться. Вот что я сделал с моим последним тестированием, чтобы все заработало:

Я использовал свой Identity Server 4, размещенный на нашем тестовом сервере, в качестве центра управления. Затем я запустил свой локальный API, чтобы я мог видеть консоль. Мне удалось получить токен, но когда я пошел запрашивать данные через Postman, я получил ту же ошибку о том, что он неавторизован. Я посмотрел на консоль, и ошибка в консоли в основном говорила о том, что полномочия не соответствовали ожидаемым. Разница оказалась косой чертой. Как только я сопоставил их в своем файле запуска, команда API сработала.

Мораль этой истории такова: убедитесь, что полномочия, которые вы установили в своем файле запуска, верны. Если у вас возникают несанкционированные проблемы, я бы сначала посмотрел там.