Форма входа
Проверяем подписи полей, автозаполнение, вставку из менеджера паролей, валидацию, CAPTCHA и понятную ошибку.
Доступ пользователя
Не работает личный кабинет на сайте
Проверяем форму входа, учётную запись, cookie, серверную сессию, права и загрузку пользовательских данных. Исправляем конкретный сценарий без запроса паролей реальных клиентов.
Авторизация и данные
На каком этапе
теряется доступ
Успешная проверка логина ещё не означает рабочий кабинет: браузер должен получить защищённую сессию, сервер — восстановить пользователя и права, а API — вернуть только разрешённые данные.
Учётная запись
Сверяем статус пользователя, способ входа, подтверждение контакта, блокировку и безопасный сброс без просмотра пароля.
Cookie и сессия
Проверяем домен, HTTPS, SameSite, срок, серверное хранилище и поведение при переключении между узлами.
Роли и доступ
Сверяем разрешения, маршруты, API и отсутствие доступа к данным другого пользователя через замену идентификатора.
Данные кабинета
Проверяем заказы, документы, профиль, интеграции и различие между пустым ответом и ошибкой загрузки.
Кэш и мобильный режим
Исключаем персональные страницы из общего кэша и тестируем вход, выход и возврат назад на разных экранах.
Результат
Пользователь видит только свои данные
Стабильный вход
Сессия сохраняется ожидаемое время и корректно завершается.
Правильные роли
Каждый маршрут и объект проверяет разрешения на сервере.
Понятное восстановление
Сброс доступа работает без раскрытия существующих учётных записей.
Контрольные роли
Тестируем не только администратора
Ошибка часто зависит от типа пользователя или старой сессии. Создаём тестовые роли и проверяем разрешённые и запрещённые действия отдельно.
Новый пользователь
Подтверждает контакт, входит и видит начальное состояние.
Постоянный клиент
Получает свои заказы и документы без смешения данных.
Сброс доступа
Одноразовая ссылка имеет срок и не работает повторно.
Запрещённый маршрут
Сервер отклоняет доступ независимо от скрытой кнопки.
Безопасность и удобство
Не блокируем менеджеры паролей
W3C WCAG 2.2 рекомендует доступную аутентификацию: корректные поля, автозаполнение и возможность вставки снижают ошибки. Защиту обеспечивают серверные проверки, ограничение попыток и безопасные сессии.
Для диагностики подготовьте
- URL входа и тип тестовой роли;
- устройство и браузер;
- точные шаги до ошибки;
- время последней попытки;
- изменения домена, CDN или авторизации.
Пароль реального пользователя не присылайте: используем отдельную тестовую учётную запись.
Контур авторизации
Вход состоит из нескольких проверок
Форма может принять данные, но сессия не создастся. Сессия может появиться, но роль не даст открыть раздел. Мы разделяем проверку учётной записи, cookie, прав и API.
Учётная запись
Проверяем статус пользователя, безопасное сравнение пароля, подтверждение контакта, блокировку попыток и восстановление доступа. Пароль не читаем и не сохраняем открытым.
Сессия
Сверяем домен и параметры cookie, HTTPS, SameSite, срок жизни и хранилище сессий. На нескольких серверах проверяем общее хранилище или закрепление запросов.
Роли
Тестовый пользователь должен видеть только разрешённые заказы, документы и настройки. Проверяем серверную авторизацию каждого запроса, а не только скрытие ссылок в интерфейсе.
Кэш и API
Персональные страницы исключаем из публичного кэша. Для SPA проверяем обновление токена, ответы 401 и 403, выход на всех устройствах и повторный вход.
Критерий восстановления
Проверяем полный цикл аккаунта
Создаём тестового пользователя без доступа к реальным данным. Выполняем вход, переход по закрытым разделам, выход, восстановление пароля и истечение сессии. На мобильном устройстве повторяем вход после закрытия браузера. Результат принимаем, когда роли соблюдаются, персональные ответы не попадают в общий кэш, а журнал не содержит повторных ошибок авторизации.
После восстановления
Контролируем вход без слежки за паролями
Отслеживаем число успешных и отклонённых попыток, ошибки создания сессии и ответы закрытых API. Метрики не содержат пароль, полный токен или персональные поля. Отдельно ставим оповещение о серии отказов после релиза.
Регламент описывает срок сессии, сброс доступа, блокировку перебора и отзыв активных токенов. При смене домена или прокси заранее проверяем параметры cookie на тестовом адресе, чтобы пользователи не попали в цикл повторного входа.
Типовые различия
Ошибка зависит от пользователя и устройства
Один администратор может входить, пока клиентский сценарий сломан. Проверяем новый и существующий аккаунт, разные роли и два браузера, чтобы не принять сохранённую сессию разработчика за исправление.
Только один аккаунт
Сверяем статус, роль, подтверждение контакта и связанные записи. Не меняем глобальные настройки входа из-за повреждённого профиля одного пользователя.
Только мобильный
Проверяем cookie, встроенный браузер приложения, автозаполнение и клавиатуру. Форма не должна терять введённые данные при повороте экрана.
После обновления
Сопоставляем версию CMS, модуль авторизации, формат сессии и миграции базы. Старые сессии завершаем предсказуемо, не оставляя пользователя в цикле редиректов.
Для проверки нужен тестовый аккаунт с той же ролью, что у пострадавшего пользователя, и точный адрес проблемного раздела. Реальные пароли не передаются. Если ошибка затрагивает персональные данные, сначала ограничиваем доступ и фиксируем объём возможного раскрытия.
Вопросы
Перед исправлением
Почему не получается войти?
Проверяем форму, аккаунт, ограничение попыток, API, cookie и создание сессии.
Почему после входа снова авторизация?
Причиной может быть cookie, HTTPS, потеря сессии, кэш или рассинхронизация серверов.
Можно посмотреть пароль?
Нет. Используем тестовый аккаунт и безопасный сброс, пароли не хранятся открыто.
Что тестируется?
Вход, выход, восстановление, роли, срок сессии, мобильная версия и защита от кэша.
Первый шаг
Опишите сценарий входа
Пришлите URL, тип тестового пользователя, устройство и шаги до ошибки. Пароль не отправляйте.