Авторизация настраивается во вкладке Auth редактора запроса и превращается в обычный заголовок или query-параметр перед отправкой. Доступны четыре типа — None, Basic Auth, Bearer Token, API Key — плюс пятый режим Inherit, при котором запрос берёт настройки у родительской коллекции. На корешке вкладки виден бейдж с выбранным типом, так что заглядывать внутрь ради проверки не нужно.
Типы авторизации#
None. Ничего не добавляется. Заголовок Authorization, выставленный вручную во вкладке Headers, при этом остаётся — Tetiva его не трогает.
Basic Auth. Поля Username и Password. Отправляется заголовок Authorization: Basic <base64(username:password)>. Кнопка с глазом рядом с паролем показывает введённое значение, если нужно свериться.
Bearer Token. Поля Prefix и Token. Prefix по умолчанию Bearer, и заголовок собирается как Authorization: Bearer <token>. Префикс можно заменить на свой — например Token — или стереть совсем: тогда в заголовок уйдёт только само значение токена, без префикса и пробела.
API Key. Поля Key, Value и переключатель Add to.
Headerкладёт пару в заголовки запроса как есть.Query Paramsдобавляет параметр в URL: значение кодируется, а одноимённый параметр, если он уже был в строке, перезаписывается.
Для режима Header пять имён запрещены — host, content-length, authorization, connection, transfer-encoding. Попытка отправить запрос с таким ключом завершится ошибкой, а не молчаливой подменой служебного заголовка. Если нужен именно Authorization, выберите Bearer или Basic.
Переменные в полях авторизации#
Все поля авторизации понимают {{переменные}}: подсветка, автодополнение по {{ и подсказка при наведении работают здесь так же, как в теле запроса. Типичная схема — держать {{token}} в поле Bearer, а само значение обновлять post-скриптом после логина.
Подстановка выполняется уже после pre-скрипта, поэтому токен, записанный скриптом через pm.environment.set, попадает в заголовок в том же прогоне. Подробнее — в разделах Окружения и переменные и Скрипты.
Наследование от коллекции#
У коллекции есть собственная авторизация: «Open Details» → вкладка Authorization. Набор типов тот же, только None здесь называется «No Auth», а вложенным коллекциям дополнительно предлагается «Inherit from parent».
Запрос с типом Inherit не хранит своих полей — он ищет настройки вверх по дереву:
- Берётся коллекция, в которой лежит запрос.
- Если у неё выбран не «No Auth» — используется её авторизация, поиск закончен.
- Если «No Auth» — тот же вопрос задаётся её родителю, и так далее до корня.
- Ничего не нашлось — запрос уходит без авторизации.
Обход ограничен 50 уровнями вложенности. На практике это защита от испорченного дерева, а не рабочий предел: коллекции такой глубины никто не строит.
Практический вывод простой. Держите общие учётные данные на верхней коллекции сервиса, оставляйте вложенным папкам «No Auth» — они прозрачны для поиска — и переопределяйте авторизацию только там, где endpoint действительно отличается, например на /auth/login, которому токен не нужен.
Порядок применения#
Перед отправкой HTTP-запроса Tetiva выполняет шаги строго по очереди: подстановка переменных → pre-скрипт → авторизация → автоматический Content-Type.
Отсюда следствие, которое иногда удивляет: авторизация записывается последней и перезаписывает заголовок, выставленный раньше. Если pre-скрипт положил свой Authorization, а во вкладке Auth выбран Bearer, отправится значение из вкладки Auth. Чтобы скрипт был главным, выберите тип None.
Где авторизация не применяется#
Настройки вкладки Auth действуют для HTTP, GraphQL и рукопожатия WebSocket.
У gRPC вкладки Auth нет: учётные данные передаются метаданными — например ключом authorization со значением Bearer {{token}}. Значения метаданных тоже поддерживают переменные, а вот наследования метаданных от коллекции нет: общий ключ для всех запросов коллекции ставится её pre-скриптом через pm.request.metadata.set — см. gRPC.
Отдельных мастеров для OAuth 2.0, Digest, AWS SigV4 и NTLM в Tetiva нет. Схемы, где подпись вычисляется по телу запроса, собираются pre-скриптом: посчитайте значение, положите его в переменную и подставьте в поле Bearer или API Key.
Где хранятся данные#
Учётные данные лежат в локальной базе SQLite рядом с остальными полями запроса и коллекции, открытым текстом. MCP-инструменты их не отдают: auth_data в ответах заменяется на [redacted], остаются только факт наличия авторизации и её тип — см. MCP-сервер.
Настройка авторизации на уровне папки описана также в разделе Коллекции.