Перейти к содержимому
Версия 1.0 ещё не выпущена; проект находится на стадии pre-MVP. См. возможности и ограничения версии 1.0.

Приёмка аутентификации

Эту проверку проводит ведущий. Документ описывает порядок действий и не подтверждает, что приёмка уже пройдена. Локальные проверки SQLite и ответы фронтенда/Cypress с заглушками подтверждают только локальное поведение. Они не подтверждают реальную доставку писем, успешные callback провайдеров или конфигурацию Cloudflare. Не выполняйте эти шаги без разрешения для выбранного развёртывания и тестовых учётных записей.

  • Используйте разрешённое развёртывание для приёмки и подготовленные тестовые учётные записи. Убедитесь, что доступен независимо проверенный способ восстановления доступа суперадминистратора.
  • Проверьте наличие необходимых привязок Worker по процедуре проверки секретов, принятой для этого развёртывания. Записывайте только наличие, никогда не значения. Проверьте включённые способы на странице Установка, в разделе Способы входа.
  • Убедитесь, что адреса фронтенда/бэкенда и зарегистрированные адреса callback провайдеров соответствуют развёртыванию: BACKEND_URL + /api/auth/callback/google или /api/auth/callback/github.
  • Используйте отдельные профили браузера для двух сессий целевого пользователя, второго активного суперадмина и неизвестной учётной записи. Удалите cookies Access из профилей, в которых проверяется только отзыв сессии, чтобы Access не мог повторно подтвердить доступ независимо от отозванной сессии.
  • Запустите frontend/cypress/e2e/journey-account-security.cy.ts в существующей локальной среде. Ведущий отвечает за запуск и визуальную проверку вживую при 390×844 и 1440×900: загрузка, пустое состояние, подключение, ошибка, длинный email, подтверждение, отказ, ожидание, успех и возврат фокуса. Одних прошедших проверок недостаточно для визуальной приёмки.
Проверка Процедура Обязательный результат
Доставка Resend Запросите magic link для известной активной учётной записи при включённом magic link. Получите его в разрешённом почтовом ящике и откройте. Реальное письмо приходит, пользователь входит именно в ожидаемую учётную запись CMS, защищённый запрос проходит. Один только ответ HTTP провайдера не подтверждает доставку.
Доставка приглашения и подтверждение адреса В разделе Настройки → Люди пригласите разрешённый почтовый ящик. Откройте ссылку из письма, введите этот адрес и код из письма. Отдельно перешлите ссылку во второй разрешённый ящик и попробуйте принять её там. Повторите использованную, отправленную заново и отменённую ссылку. Оба письма приходят, после принятия назначается именно та роль и именно на том сайте, которые указаны в приглашении, новый пароль позволяет войти. По пересланной ссылке нельзя принять приглашение без кода из исходного почтового ящика. Использованная, заменённая и отменённая ссылки отклоняются одинаково.
Повторное использование magic link и истечение срока Снова откройте использованную ссылку. Запросите две ссылки, затем попробуйте более старую. Отдельно сохраните неиспользованную ссылку дольше её 15-минутного срока и попробуйте открыть её. Использованная, заменённая и истёкшая ссылки не могут создать ещё одну сессию. Запрос для неизвестного адреса даёт тот же публичный ответ и не создаёт учётную запись.
Callback Google Войдите с реальной учётной записью Google, подтверждённый email которой совпадает с адресом подготовленной учётной записи CMS. Попробуйте другой неизвестный email и неподтверждённый адрес, если провайдер позволяет подготовить такой тестовый аккаунт с разрешения владельца. Та же учётная запись CMS, без дубликата и регистрации неизвестного email. Вход с неподтверждённым адресом отклоняется. Если реальный аккаунт с таким адресом недоступен, отметьте этот сценарий как непроверенный. Не заменяйте его заглушкой и не отмечайте как пройденный.
Callback GitHub Используйте реальную учётную запись GitHub, основной подтверждённый email которой совпадает с адресом подготовленной учётной записи CMS. На учётных записях, разрешённых для проверки, проверьте поведение при скрытом публичном email и при несовпадении основного email. Используется основной подтверждённый адрес GitHub. Совпадение только вторичного адреса не позволяет войти в учётную запись CMS. Неизвестная или несовпадающая учётная запись отклоняется.
Повтор OAuth/неверное состояние Повторно откройте использованный callback и callback с истёкшим или неверным state в браузере, не сохраняя URL callback или коды авторизации в материалах проверки. Повторное, неверное или истёкшее подтверждение не создаёт сессию или привязку провайдера.
Отзыв при привязке и удаление токенов Войдите через только что привязанного провайдера, пока старая сессия CMS существует в другом профиле. Проверьте старую сессию защищённым API. Выполните разрешённую проверку БД, которая возвращает только признаки наличия токенов провайдера, а не их значения. Старая сессия отклоняется. Столбцы access, refresh и ID token провайдера остаются null. Никогда не экспортируйте эти столбцы или их значения.
Отвязка и отзыв сессий Создайте две сессии CMS одного пользователя. Откройте Безопасность аккаунта, один раз отмените, затем подтвердите отвязку Google. Независимо повторите для GitHub. Проверьте обе старые сессии защищённым запросом. Отмена ничего не меняет. Подтверждение удаляет только выбранное подключение пользователя, отправившего запрос, завершает вход в текущем интерфейсе, обе старые сессии перестают работать. Подключения и сессии других пользователей остаются действующими. Войдите заново, чтобы проверить оставшиеся подключения.
Отвязка последнего провайдера обычного пользователя Используйте обычного пользователя с единственным подключением OAuth, пока отдельный активный суперадмин сохраняет рабочий способ. Отвязка проходит, все сессии целевого пользователя завершаются. Восстановление или последующий вход провайдером с тем же email — отдельный шаг.
Последний суперадминистратор с работающим способом входа В разрешённом изолированном развёртывании для приёмки сделайте целевого провайдера единственным работающим способом входа для всех активных суперадминистраторов, сохранив утверждённый путь восстановления оператора. Попробуйте отвязать. Затем подготовьте другого активного суперадмина с проверенным работающим способом входа и повторите. Первая попытка возвращает 409 would_lock_out_superadmins. Учётная запись и сессии сохраняются. Вторая попытка может пройти, даже если у целевого пользователя не останется личного способа. Отключённые, незавершённые или непривязанные альтернативы не считаются.
Ключ доступа на реальном устройстве При включённых ключах доступа войдите другим способом и добавьте ключ в разделе Безопасность аккаунта на ноутбуке (Touch ID или Windows Hello) и на телефоне. Выйдите и используйте Войти с ключом доступа на каждом. Переименуйте один ключ и удалите другой. Попробуйте добавить ключ из сессии старше 24 часов. На каждом устройстве выполняется вход в ожидаемую учётную запись CMS без ввода адреса. С удалённым ключом войти больше нельзя. При попытке добавить ключ из старой сессии система просит сначала войти заново.
Восстановление при потере устройства с ключом Для учётной записи, у которой кроме ключа есть только пароль, уберите доступ к устройству с ключом. Войдите по паролю, удалите потерянный ключ и попробуйте его снова. При включённых почте и ссылках для входа повторите с учётной записью, у которой есть только ключ, используя ссылку для входа по email вместо пароля. Отдельно деактивируйте учётную запись с ключом и попробуйте войти по нему. Вход по паролю работает, удалённый ключ отклоняется. Последний оставшийся способ удалить нельзя. Деактивированная учётная запись не получает сессию.
Активация первого администратора при приёмке новой установки На новых установках, отдельно разрешённых для этой проверки, используйте привязанную ссылку активации с каждым выбранным способом. Попробуйте неверный email, использованные и истёкшие ссылки. Никогда не сбрасывайте существующее развёртывание ради этой проверки. Только привязанный email может создать первого суперадмина. Использованные и просроченные ссылки отклоняются. Обычный вход никогда не создаёт пользователей.

Как зафиксировать результаты без раскрытия секретов

Заголовок раздела «Как зафиксировать результаты без раскрытия секретов»

Запишите метку/версию развёртывания, дату, способ, сценарий, ожидаемый и наблюдаемый результат, статус/причину ответа и итог pass/fail/unverified. На снимках может быть состояние интерфейса со скрытыми личными адресами. Записывайте только логические значения или сравнения количества при проверке неизменности учётных записей и сессий и только через разрешённый доступ.

Не сохраняйте cookies, токены сессий, пароли, ссылки активации, ссылки из писем, коды/state OAuth, идентификаторы учётных записей у провайдера, токены провайдера, значения секретов. Не сохраняйте полные дампы БД или неотредактированные экспорты HAR/сети. Профили браузера с сессиями приёмки содержат учётные данные. После проверки их нужно закрыть или завершить в них сессии.

  • Запуск ведущим соответствующего теста Cypress и визуальная проверка вживую в обоих разрешениях.
  • Реальная приёмка Resend (magic link и приглашения), Google, GitHub и ключей доступа на реальных устройствах, включая описанные выше применимые отрицательные сценарии, повторное использование одноразовых данных и истечение их срока действия.
  • Проверка наличия секретов в живом Cloudflare.
  • Развёртывание сайта документации после стандартной проверки владельцем.

Записывайте результаты отдельно после выполнения. Эта процедура сама по себе не подтверждает успешное развёртывание или работу провайдера.


Стабильная версия ещё не выпущена (pre-MVP)
Коммит исходного кода: fe23db481c422b40e317b92fc98116b4c0c26a87 (с локальными изменениями)
Дата сборки (UTC): 2026-10-18T09:22:34.630Z
Коммит для обновления: не определён: в рабочей копии есть изменения. Примечания к выпуску