Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Что такое HTTP-код состояния 401?
HTTP-код состояния 401 (англ. 401 Unauthorized) — это статусный код протокола HTTP уровня клиентских ошибок (4xx), который сервер возвращает, когда запрос требует аутентификации пользователя, но она либо не была предоставлена, либо предоставленные учётные данные недействительны, просрочены или недостаточны для доступа к запрашиваемому ресурсу.
Ключевые особенности кода 401
- Относится к аутентификации (Authentication): Он указывает на проблему с идентификацией пользователя ("кто вы?"). Это важно отличать от кода 403 (
Forbidden), который означает, что сервер знает, кто пользователь (аутентификация прошла успешно), но у него нет прав (авторизации) для выполнения запроса. - Требует повторной отправки запроса с учётными данными: В ответ с кодом 401 сервер обязательно должен включить HTTP-заголовок
WWW-Authenticate. Этот заголовок сообщает клиенту, какой именно метод аутентификации (Basic,Bearer,Digestи т.д.) и область доступа (realm) ожидаются. - Непостоянная ошибка (Transient Client Error): Ошибка вызвана состоянием клиента (отсутствием или неверными учётными данными). Клиент может её исправить, отправив корректные данные.
Типичные сценарии получения 401-кода
- Отсутствие учётных данных: Пользователь пытается получить доступ к защищённому API-эндпоинту или веб-странице, не передав токен, логин/пароль или cookie сессии.
GET /api/v1/profile HTTP/1.1 Host: example.com
Сервер ответит:
```http
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="Protected API", charset="UTF-8"
```
2. Неверные или просроченные учётные данные:
* Истёкший JWT-токен (JSON Web Token).
* Неверный пароль при использовании Basic-аутентификации.
* Отозванный или поддельный OAuth-токен.
- Некорректный формат учётных данных: Например, клиент отправил токен в заголовке
Authorization, но в неверном формате.GET /secure-data HTTP/1.1 Host: example.com Authorization: Token 12345abcde # Ожидается "Bearer 12345abcde"
Как выглядит ответ сервера?
Пример полного ответа сервера при попытке доступа к ресурсу, защищённому Basic-аутентификацией:
HTTP/1.1 401 Unauthorized
Date: Tue, 17 Sep 2024 12:00:00 GMT
WWW-Authenticate: Basic realm="Access to staging site"
Content-Type: application/json
Content-Length: 45
{
"error": "Unauthorized",
"message": "Valid credentials required"
}
Роль QA-инженера при тестировании 401-кода
Для QA-инженера проверка обработки 401-кода — критически важная часть тестирования безопасности и надёжности API и веб-приложений.
Основные проверки (чек-лист):
- Позитивный сценарий: Убедиться, что после получения 401-кода приложение корректно запрашивает учётные данные (например, показывает форму логина) и после их ввода предоставляет доступ.
- Негативные сценарии (Security Testing):
* Запрос к защищённому ресурсу **без** токена/учётных данных. *Ожидаемый результат: `401 Unauthorized`.*
* Запрос с **просроченным** токеном (JWT). *Ожидаемый результат: `401 Unauthorized` (часто с сообщением `Token expired`).*
* Запрос с **неверным форматом** токена (например, отправить `BearerToken` вместо `Bearer Token`). *Ожидаемый результат: `401 Unauthorized` или `400 Bad Request`.*
* Запрос с **поддельным** или случайно сгенерированным токеном. *Ожидаемый результат: `401 Unauthorized`.*
- Проверка заголовка
WWW-Authenticate: Убедиться, что сервер всегда возвращает этот заголовок в ответе 401, и его значение корректно (правильныйrealm, схема аутентификации). - Тестирование восстановления доступа: Проверить работу механизма refresh-токена (если он есть). После получения 401 из-за истечения срока действия access-токена, приложение должно автоматически, используя refresh-токен, получить новую пару токенов и повторить запрос.
- Поведение клиентского приложения (Frontend): Проверить, как веб- или мобильное приложение реагирует на 401.
* Происходит ли **перенаправление на страницу входа**?
* **Сохраняется ли контекст** (пользователь не должен потерять введённые данные в форме)?
* Выводится ли понятное **сообщение об ошибке** для пользователя?
* Не попадает ли приложение в **бесконечный цикл** перенаправлений (redirect loop)?
Пример теста на Python с использованием библиотеки requests
import requests
import pytest
# Базовый URL API
BASE_URL = "https://api.example.com"
def test_access_without_token_should_return_401():
"""Попытка доступа к защищённому эндпоинту без токена должна вернуть 401."""
endpoint = f"{BASE_URL}/secure-data"
response = requests.get(endpoint)
assert response.status_code == 401, f"Ожидался статус 401, получен {response.status_code}"
assert 'WWW-Authenticate' in response.headers, "В ответе отсутствует обязательный заголовок WWW-Authenticate"
assert 'Bearer' in response.headers['WWW-Authenticate'], "Схема аутентификации должна быть Bearer"
def test_access_with_expired_token_should_return_401():
"""Попытка доступа с просроченным токеном должна вернуть 401."""
endpoint = f"{BASE_URL}/secure-data"
expired_token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
headers = {'Authorization': f'Bearer {expired_token}'}
response = requests.get(endpoint, headers=headers)
assert response.status_code == 401
# Дополнительно можно проверить тело ответа на наличие сообщения об истечении срока
response_body = response.json()
assert "expired" in response_body.get("message", "").lower()
# Позитивный тест для сравнения
def test_access_with_valid_token_should_return_200():
"""Успешный доступ с валидным токеном."""
endpoint = f"{BASE_URL}/secure-data"
valid_token = get_valid_token() # Предполагаемая функция для получения токена
headers = {'Authorization': f'Bearer {valid_token}'}
response = requests.get(endpoint, headers=headers)
assert response.status_code == 200, "С валидным токеном запрос должен быть успешным"
Вывод для QA: 401-код — это не ошибка сервера, а стандартный механизм HTTP для защиты ресурсов. Корректная обработка этого кода как на стороне сервера (возврат правильных заголовков), так и на стороне клиента (интуитивное поведение для пользователя) напрямую влияет на безопасность и удобство использования приложения. Всестороннее тестирование сценариев, приводящих к 401, является обязательным.