Использование скриптов при формировании запросов используя Postman
Бесплатные
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Узнавайте о новых бесплатных решениях в нашей телеграм-группе Инфостарт БЕСПЛАТНО
Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Вводные
Нужно протестировать работоспособность API в которых:
- Используется подпись в теле запроса, пример Mango office API (документация)
- Используется Oauth аутентификация с RS256, пример Google API используя сервисного пользователя (документация)
- Используется Oauth аутентификация, пример Google API используя доступ обычного пользователя (документация)
- Используется JWT токен HS256, пример Zoom (документация)
- Тестирую с помощью Postman
Описание варианта с подписью
Выдержка из документации: "Данные, которыми обмениваются системы, как правило, будут передаваться в теле POST-запроса. В этом случае в тело запроса включается обязательные параметры json, vpbx_api_key и sign.
Параметр vpbx_api_key заполняется уникальным кодом продукта ВАТС, полученным в Личном кабинете MANGO OFFICE при подключении API.
Значение sign рассчитывается следующим образом: sign = sha256(vpbx_api_key + json + vpbx_api_salt).
Подписываются все запросы — как от внешней системы, так и от API ВАТС."
Решение варианта с подписью
Можно собрать тело запроса вручную, рассчитав хэш SHA256 используя онлайн сервис или написав обработку в 1С, но для тестирования набора запросов с разными данными это неудобно.
В postman поддерживаются переменные (документация) и обработчики перед и после отправки запроса (документация).
Обработчики пишутся на JS, ими можно установить переменную, нельзя переписать тело запроса. Поэтому для решения задачи помещаем переменную {{content_body}} в тело запроса
и реализуем её расчет для Pre-request script
Расчет подписи используется для всей коллекции при этом данные определяются на уровне запроса. Для решения задачи код нужно установить в коллекцию. Код коллекции выполняется раньше кода запроса, поэтому код коллекции нужно обернуть для возможности вызова из кода коллекции.
Описание варианта с Oauth аутентификацией используя сервисного пользователя
Для работы с сервисом нужен токен доступа, для получения которого нужно отправить JWT запрос, у Google применяется формат JWT RS 256, в котором используется RSA.
Решение варианта с Oauth аутентификацией используя сервисного пользователя
Реализовать получение токена в обработчике перед запросом. Кешировать токен в переменных окружения с фиксацией срока действия.
Решение нашел по адресу https://gist.github.com/dinvlad/425a072c8d23c1895e9d345b67909af0
Для корректной работы в переменную "serviceAccountKey" нужно записать содержимое JSON ключа созданного для сервисного пользователя.
В скрипте скачивается внешний JS скрипт и кешируется в переменной "jsrsasign".
Ключ выдается под определенные права доступа (scopes), но в переменных не фиксируется на какие права был выдан токен, поэтому при использовании сервиса с другими правами доступа нужно вручную удалить токен и срок действия из переменных для получения нового токена.
При наличии нескольких коллекций под разные сервисы переменные окружения (pm.environment) можно перевести в переменные коллекции (pm.collectionVariables).
Описание варианта с Oauth аутентификацией с ручным получением ключа
Формируем GET запрос, переносим в браузер, на уровне браузера подтверждаем права доступа, получаем код.
Используем код для получения access и refresh токенов
Решение варианта с Oauth аутентификацией с ручным получением ключа
Формируем GET запрос с параметрами, запускаем, берем из консоли строку запроса. берем первую, потому что остальные это автообработка редиректов postman-ом .
Полученный код добавляем в переменные коллекции и выполняем запрос на получение ключа, в вкладке tests добавляем скрипт обработки полученных данных
В результате успешного выполнения скрипта заполнились значения переменных с ключами, которые можно использовать в дальнейшей работе в рамках коллекции.
Описание варианта с JWT HS256 токеном
При каждом запросе формируется JWT токен с ключом и датой окончания действия, который помещается в заголовок запроса
Решение варианта с JWT HS256 токеном
Итог
Postman удобный инструмент для тестирования API, работа с ним при использовании скриптов становится более производительной.
Благодарю за внимание.
Вступайте в нашу телеграмм-группу Инфостарт
