Многие из нас хотя бы раз сталкивались с интеграцией сторонних сервисов на проектах. Обычно такую функциональность мы тестируем вручную, авторизуясь через Google-аккаунт и подобные сервисы.
Когда же дело доходит до тестирования API, часто возникает вопрос: как можно автоматизировать этот процесс? Какой способ генерации токенов даст больше преимуществ в случае одной интеграции… А в случае десятка?
В этой статье я хочу описать основные способы авторизации OAuth 2.0
Авторизации через сервис-аккаунт часто бывает достаточно для получения доступа к ресурсам во время автотестов. Но бывают ситуации, когда нам нужно знать, кто заходит в систему, какие права есть у пользователя и так далее. В таких случаях нам нужно использовать веб-сервер-авторизацию, которая требует действий пользователя. Об этом и поговорим.
В целом, OAuth 2.0 Authorization code flow включает в себя:
Наиболее проблемная для автоматизации часть сценария — второй пункт, поскольку реализация может варьироваться в зависимости от сервиса, и мы не можем контролировать, каким способом сервис обрабатывает аутентификацию пользователя. Кроме того, здесь требуются действия пользователя.
Отталкиваясь от требований проекта, мы можем реализовать сценарий авторизации OAuth2.0 двумя способами:
Основная идея этого подхода — использовании только HTTP-протокола для авторизации пользователя, включая отправку сервису учетных данных пользователя.
Перед реализацией нам необходимо собрать следующую информацию:
Получив все необходимые данные, мы можем перейти к реализации сценария авторизации.
Ниже я привожу пример модуля авторизации для Box Service, реализованного на PowerShell.
Самая трудоемкая часть этого подхода связана с общей формой входа и подтверждения пользователя, поскольку нам нужно выяснить, как передать учетные данные пользователя в запрос и какие заголовки нужны, чтобы запрос работал.
Преимущества | Недостатки |
1. Стабильность. Скрипт работает стабильно по сравнению с подходом, когда мы взаимодействуем с браузером.
2. Быстрый запуск. Поскольку мы не настраиваем драйвер, это экономит время при запуске скрипта.
3. Не требует дополнительных настроек в CI. | 1. Довольно долгое время на реализацию из-за особенностей реализации OAuth 2.0 конкретного стороннего сервиса.
2. Требует конфиденциальной информации, например client_secret. |
Основная идея — выполнить самую трудоемкую часть подхода №1 с помощью веб-драйвера.
Данные, которые нужно собрать:
Ниже можно найти UML-диаграммы этого подхода:
Здесь переиспользуемые классы отмечены зеленым. Единственное, что нужно добавить для подключения нового стороннего сервиса — это объект страницы AuthForm для соответствующего сервиса (оранжевый класс на изображении).
Преимущества | Недостатки |
1. Быстрая реализация. Самая трудоемкая часть реализуется с помощью веб-драйвера, что ускоряет процесс реализации.
2. Не требует конфиденциальной информации, такой как client_secret.
3. Флоу можно использовать повторно. | 1. Исполнение может занять больше времени из-за необходимости настройки и старта веб-драйвера.
2. Требует дополнительной контейнеризации в CI.
3. Имеется риск нестабильности процесса авторизации из-за использования веб-драйвера. |
Оба подхода имеют свои недостатки и преимущества и могут быть реализованы в рамках автоматизации тестов. Но давайте обозначим условия, при которых мы можем извлечь из каждого подхода максимум преимуществ.
Если ваш проект интегрируется с одним сторонним сервисом, можно использовать только HTTP-запросы для авторизации. С подходом №1 вы потратите больше времени на реализацию, но это произойдет только один раз.
Если же есть две или больше интеграций со сторонними сервисами, лучшим вариантом будет подход №2, так как он экономит много времени во время реализации механизма авторизации.
Если у вас нет конфиденциальной или другой специфической информации, необходимой для авторизации через HTTP-запрос, также лучше использовать подход №2, поскольку все атрибуты, требующиеся для отправки пользовательских учетных данных на сервер, формируются в браузере автоматически в процессе авторизации через UI.
Читайте также: Фичи Postman, которые облегчат жизнь тестировщика: пошаговая инструкция с видео
В благословенные офисные времена, когда не было большой войны и коронавируса, люди гораздо больше общались…
Вот две истории из собственного опыта, с тех пор, когда только начинал делать свою карьеру…
«Ты же программист». За свою жизнь я много раз слышал эту фразу. От всех. Кто…
Отличные новости! Если вы пропустили, GitHub Copilot — это уже не отдельный продукт, а набор…
Несколько месяцев назад мы с командой Promodo (агентство инвестировало в продукт более $100 000) запустили…
Пару дней назад прочитал сообщение о том, что хорошие курсы могут стать альтернативой классическому образованию.…