Авторизация в Postman
↑ 1.5 Postman: от установки до коллекций · ← Предыдущая · → Следующая
Зачем это аналитику и PM
Один и тот же метод без допуска отвечает 401, хотя тело верное. В клиенте допуск задают отдельно от тела, часто один раз на коллекцию, и не вставляют секрет в каждый запрос руками.
План темы
- API key, Bearer, Basic, OAuth 2.0
- наследование авторизации от коллекции
- получение токена скриптом
Объяснение
Зона Authorization у запроса или у коллекции описывает, как предъявить допуск. Это не поле заказа. Клиент сам собирает заголовок. Вам не нужно помнить Base64, если выбран тип Basic и введены учебные имя и пароль.
Как пропуск на папку опытов. Если пропуск повесили на всю коллекцию, отдельные запросы могут его унаследовать. Если у одного запроса свой пропуск, он не берёт общий. Точные подписи режимов сверьте с версией: слова API key, Bearer, Basic и OAuth 2.0 держатся давно, место переключателя могли перенести.
Типы
Ключ API — имя заголовка и значение. Имя берёте из документации вашего API, не из чужого скрина. Bearer — слово Bearer и токен. В поле кладут сам токен, без слова Bearer, если программа дописывает его сама. Basic — имя и пароль: по сети уходит заголовок, не пара полей. OAuth 2.0 в клиенте — помощник, который получает токен у провайдера. Тип выдачи и адреса копируют из документации провайдера.
Наследование и скрипт
Удобно задать допуск на коллекции, а у запроса оставить наследование. Тогда смена токена одна, а не в двадцати вкладках. Запрос, которому нужен другой субъект, наследование выключает и задаёт свой допуск. Если подписи «наследовать» в вашей версии нет, ищите выбор типа допуска «как у родителя» и запишите фактическое имя.
Скрипт до отправки имеет смысл, когда токен надо получить или обновить самому. Готовый скрипт берут у команды: там адреса вашего контура. Скрипт не печатает токен в консоль и не пишет его в описание запроса. Куда он кладёт значение — в переменную окружения, — видно из двух строк примера, без живого секрета.
Примеры
Схема заголовка, который вы хотите увидеть уже собранным. Токен вымышлен.
GET /todos/1 HTTP/1.1
Host: jsonplaceholder.typicode.com
Authorization: Bearer eyJ...Учебный JSONPlaceholder этот заголовок не проверяет. Он годится, чтобы увидеть, куда клиент подставил допуск, а не чтобы доказать права.
Фрагмент скрипта, который лишь кладёт маску в переменную. На бой так не отправляют.
pm.environment.set("token", "***");В допуске коллекции тогда ссылаются на переменную, а не вставляют секрет в текст запроса. Как в вашей версии выглядит ссылка на переменную в поле токена, сверьте на экране.
Нюансы и подводные камни
- Допуск коллекции не заменяет роль. Верный токен всё равно может получить 403.
- Токен test в окружении prod — удар по бою. Имя окружения читают до отправки.
- Помощник OAuth сохраняет токен у клиента. Не выгружайте это хранилище в общий файл.
- Если итоговый заголовок содержит Bearer дважды, слово уже было в значении. Оставьте его в одном месте.
Практика
На учебной коллекции задайте Bearer через переменную с маской и откройте итоговые заголовки запроса, не отправляя секрет в чат.
Ожидаемый результат: в заголовке ровно одно слово Bearer и маска либо учебный токен, который вам выдали для test. На запросе видно, унаследован допуск или задан местный. Боевого значения в описании нет.
Вопросы с ответами
Куда вставлять токен: в Headers или в Authorization?
В Authorization, если тип Bearer или Basic есть в списке. Клиент соберёт заголовок. Ручной Headers нужен, когда документация требует нестандартное имя, и тогда тип лучше оставить пустым, чтобы не получить два допуска сразу.
Зачем допуск на коллекции?
Чтобы не копировать секрет в каждый запрос и сменить его один раз. Отдельный запрос от другого субъекта наследование отключает.
Можно ли описать OAuth только словами «как в Postman»?
Нет. Нужны тип выдачи и адреса из документации провайдера. Кнопка в клиенте их не угадывает.
Где хранить скрипт обновления токена?
В pre-request коллекции, если токен нужен всем её запросам, и только скрипт, который дала команда. Секрет в текст скрипта в репозиторий не коммитят.