В заголовке Authorization отправляется токен Bearer в виде `Authorization: Bearer <token>` , который авторизует запрос исключительно путем предъявления. Запрос не подписывается, нет подтверждения того, что отправитель является стороной, которой был выдан токен: токен представляет собой все учетные данные, что и означает слово "bearer" .
Сервер проверяет токен — путем поиска в базе данных или проверки подписи, если он является самодостаточным, например, JWT, — и на его основе определяет личность и права доступа вызывающей стороны. Отсутствующий или недействительный токен приводит к ошибке 401. Действительный токен, владелец которого не имеет права выполнять это действие, приводит к ошибке 403; разница имеет значение, поскольку исправить можно только одну из этих ошибок, получив новый токен.
Токен Bearer можно безопасно размещать в URL-адресе, потому что он истекает. Все, что содержится в URL-адресе, попадает в журналы сервера, историю браузера, заголовки Referrer и аналитику. Токены Bearer должны размещаться в заголовке, передаваться по протоколу TLS, иметь короткий срок действия и механизм обновления.
Для каждой конечной точки, помеченной блокировкой, требуется `qa-admin-token` или `qa-viewer-token` . Использование токена пользователя при выполнении команды DELETE — самый простой способ увидеть разницу между ошибками 401 и 403: токен действителен, но ответ по-прежнему отрицательный.
Все термины · Приёмы тестирования · Все 39 mock REST API
Последнее обновление