1. Обзор
В этом руководстве мы проанализируем, как мы можем пройти аутентификацию с помощью REST Assured для правильного тестирования и проверки защищенного API.
Инструмент обеспечивает поддержку нескольких схем аутентификации :
- Базовая аутентификация
- Дайджест-аутентификация
- Аутентификация формы
- OAuth 1 и OAuth 2
И мы увидим примеры для каждого из них.
2. Использование базовой аутентификации
Базовая схема аутентификации требует, чтобы потребитель отправил идентификатор пользователя и пароль, закодированные в Base64 .
REST Assured предоставляет простой способ настроить учетные данные, которые требуются для запроса:
given().auth()
.basic("user1", "user1Pass")
.when()
.get("http://localhost:8080/spring-security-rest-basic-auth/api/foos/1")
.then()
.assertThat()
.statusCode(HttpStatus.OK.value());
2.1. Упреждающая аутентификация
Как мы видели в предыдущем посте об аутентификации Spring Security , сервер может использовать механизм запроса-ответа, чтобы явно указать, когда потребителю требуется аутентификация для доступа к ресурсу.
По умолчанию REST Assured ожидает запроса сервера перед отправкой учетных данных.
В некоторых случаях это может вызвать проблемы, например, когда сервер настроен на получение формы входа вместо ответа на запрос.
По этой причине библиотека предоставляет упреждающую директиву, которую мы можем использовать:
given().auth()
.preemptive()
.basic("user1", "user1Pass")
.when()
// ...
При этом REST Assured отправит учетные данные, не дожидаясь неавторизованного ответа.
Мы вряд ли когда-либо заинтересованы в тестировании способности сервера бросать вызов. Поэтому обычно мы можем добавить эту команду, чтобы избежать осложнений и накладных расходов, связанных с выполнением дополнительного запроса.
3. Использование дайджест-аутентификации
Несмотря на то, что это также считается «слабым» методом аутентификации , использование дайджест-аутентификации дает преимущество перед базовым протоколом.
Это связано с тем, что эта схема позволяет избежать отправки пароля в открытом виде.
Несмотря на эту разницу, реализация этой формы аутентификации с помощью REST Assured очень похожа на ту, которой мы следовали в предыдущем разделе:
given().auth()
.digest("user1", "user1Pass")
.when()
// ...
Обратите внимание, что в настоящее время библиотека поддерживает только аутентификацию с вызовом для этой схемы, поэтому мы не можем использовать preemptive() , как делали ранее.
4. Использование аутентификации с помощью формы
Многие службы предоставляют HTML-форму для аутентификации пользователя путем заполнения полей своими учетными данными.
Когда пользователь отправляет форму, браузер выполняет POST-запрос с информацией.
Обычно форма указывает конечную точку, которую она будет вызывать, с ее атрибутом действия , и каждое поле ввода соответствует параметру формы, отправленному в запросе.
Если форма входа достаточно проста и соответствует этим правилам, то мы можем положиться на REST Assured, чтобы определить эти значения для нас:
given().auth()
.form("user1", "user1Pass")
.when()
// ...
В любом случае это неоптимальный подход, так как REST Assured должен выполнить дополнительный запрос и проанализировать HTML-ответ, чтобы найти поля.
Мы также должны иметь в виду, что процесс все еще может завершиться ошибкой, например, если веб-страница сложная или если служба настроена с контекстным путем, который не включен в атрибут действия .
Поэтому лучшим решением будет предоставить конфигурацию самим, указав явно три обязательных поля:
given().auth()
.form(
"user1",
"user1Pass",
new FormAuthConfig("/perform_login", "username", "password"))
// ...
Помимо этих базовых конфигураций, REST Assured поставляется с функциями:
- обнаружить или указать поле токена CSRF на веб-странице
- использовать дополнительные поля формы в запросе
- логировать информацию о процессе аутентификации
5. Поддержка OAuth
OAuth технически является структурой авторизации и не определяет никакого механизма аутентификации пользователя.
Тем не менее, его можно использовать в качестве основы для построения протокола аутентификации и идентификации, как в случае с OpenID Connect .
5.1. ОАут 2.0
REST Assured позволяет настроить токен доступа OAuth 2.0 для запроса защищенного ресурса:
given().auth()
.oauth2(accessToken)
.when()
.// ...
Библиотека не предоставляет никакой помощи в получении токена доступа, поэтому нам придется выяснить, как это сделать самостоятельно.
Для потоков учетных данных клиента и пароля это простая задача, поскольку токен получается путем простого представления соответствующих учетных данных.
С другой стороны, автоматизация потока кода авторизации может быть не такой простой, и нам, вероятно, также понадобится помощь других инструментов.
Чтобы правильно понять этот процесс и то, что нужно для получения токена доступа, мы можем взглянуть на этот замечательный пост на эту тему.
5.2. ОАут 1.0а
В случае OAuth 1.0a REST Assured предоставляет метод, который получает ключ потребителя, секрет, токен доступа и секрет токена для доступа к защищенному ресурсу:
given().accept(ContentType.JSON)
.auth()
.oauth(consumerKey, consumerSecret, accessToken, tokenSecret)
// ...
Этот протокол требует пользовательского ввода, поэтому получение последних двух полей не будет тривиальной задачей.
Обратите внимание, что нам нужно будет добавить зависимость scribejava-apis в наш проект, если мы используем функции OAuth 2.0 с версией до 2.5.0 или если мы используем функциональность OAuth 1.0a.
6. Заключение
В этом руководстве мы узнали, как пройти аутентификацию для доступа к защищенным API с помощью REST Assured.
Библиотека упрощает процесс аутентификации практически для любой реализованной нами схемы.
Как всегда, рабочие примеры с инструкциями мы можем найти в нашем репозитории Github .