Диагностика - Veriqa

Ищите симптом по тексту ошибки — большинство из них означает не то, что кажется на первый взгляд.

Отказы на `/connect/authorize` и `/connect/token`

Симптом	Причина и что делать
`invalid_request` · `ID2029` — `The mandatory 'code_challenge' parameter is missing`	Этому клиенту PKCE обязателен: он зарегистрирован как public. Либо добавьте PKCE, либо сделайте клиента confidential — коробочные плагины CMS обычно требуют второго.
`invalid_request` · `ID2054`	То же самое, формулировка новее.
`invalid_request` · `ID2032` — `The specified 'code_challenge_method' is not supported`	Прислан `code_challenge_method=plain`. Поддерживается только `S256`. Один и тот же `ID2032` покрывает несколько отказов «не поддерживается» — ориентируйтесь на `error` и `error_description`, а не на номер.
`unsupported_response_type` · `ID2032` — `The specified 'response_type' is not supported`	Клиент просит implicit flow (`response_type=token` или `id_token`). Veriqa принимает только `code`: implicit убран в OAuth 2.1 как небезопасный. Классика — штатный модуль `auth_oauth` у Odoo; что ставить вместо него, написано на странице Veriqa в рабочих системах.
`invalid_target` · `ID2190` — `One of the specified 'resource' parameters is invalid`	Клиент шлёт параметр `resource` (индикаторы ресурса RFC 8707). Veriqa их не регистрирует, поэтому любое значение отвергается. Так ведёт себя плагин `auth_oidc` у Moodle, писанный под Microsoft Entra ID, — разбор на странице Veriqa в рабочих системах. Для клиента, которому это не отключить, включите квирк уровня клиента `drop-resource-parameter`.
`invalid_request` · `ID2087` — `Multiple client credentials cannot be specified`	Клиент шлёт учётные данные и заголовком `Authorization: Basic`, и в теле запроса, а RFC 6749 §2.3.1 разрешает один способ. Классика Joomla: снимите галочку «In Header».
Отказ токен-эндпоинта на запросе плагина CMS	Лишний `scope` в запросе `grant_type=authorization_code`. Разбор и два варианта решения — на странице WordPress.
`invalid_grant` · `ID2001`	Код авторизации испорчен или просрочен.
`400` · `ID2083` — `This server only accepts HTTPS requests`	Issuer открыт по `http`. Обратите внимание: `redirect_uri` по `http` при этом принимается — симптом относится именно к адресу issuer.
`access_denied` на `redirect_uri`	Пользователь отклонил подтверждение. Это не ошибка интеграции.

Отказы на подтверждении

Симптом	Причина и что делать
`503 channel_display_failed`	Не включён ни один канал.
`400 no_channel_for_required_phone` на `/connect/authorize`	Номер телефона обязателен, а ни один из доступных запросу каналов дать его не может — их мог сузить `acr_values`. Требование задаёт `RequirePhone` или `Level: Required` у `phone_number` в `Veriqa:ScopesClaims`, `RequirePhone` или `ClaimLevels` записи клиента либо `essential: true` у `phone_number` в параметре `claims` запроса. Если требование из конфигурации не может выполнить ни один зарегистрированный канал, об этом уже предупреждала запись в логе при старте. Включите канал, который даёт номер телефона, или снимите требование.
`400` · `browser_nonce_mismatch` — `Browser nonce does not match` на `/connect/authorize/callback`	Подтверждена не та транзакция: страница authorize успела перезагрузиться, а разовая кука браузера привязана к последней загрузке. Это штатная защита от подтверждения чужой сессии. Повторите вход, не перезагружая страницу.
`500` · `email_delivery_failed` на `/auth/email/start`, срабатывает через раз	Известное ограничение: на SMTP без аутентификации отправитель переподключается по уже открытому соединению, и каждая вторая попытка падает. Повторный запрос проходит.
`429` на `/auth/email/start`	Штатный rate limit канала Email после нескольких запросов подряд. При отладке закладывайте паузу.

Симптомы на стороне приложения

Симптом	Причина и что делать
Немое `Login failed! Please try again.` в TYPO3 при зелёных логах Veriqa	У пользователя нет группы: не задан `usersDefaultGroup`. Причина логируется уровнем INFO и не видна при дефолтном логгере TYPO3 — см. TYPO3.
`No email address provided by <provider>` в Drupal	Канал не отдал email, а Drupal требует его на каждом входе. Решение — на странице Drupal.
WordPress возвращает на `wp-login.php?login-error=invalid_request`	Тот же лишний `scope` в обмене кода — см. WordPress.
В Битриксе вход всегда происходит под администратором	Фильтр `CUser::GetList` с D7-синтаксисом молча отброшен, и выбирается первый пользователь. Разбор — на странице Битрикс.
В Moodle «Error in OpenID Connect. Please check logs for more information.»	Moodle не пошёл до Veriqa вовсе: сработала его защита исходящих запросов — по адресу (`curlsecurityblockedhosts`) или по порту (`curlsecurityallowedport`, по умолчанию только 443 и 80). Настоящая причина (`The URL is blocked.`) видна лишь после включения `debugmode` у плагина. Порт блокируется и на публичном адресе — см. Veriqa в рабочих системах.
В Moodle «The given username contains invalid characters»	Moodle строит логин из `sub` Veriqa, а он имеет вид `telegram:1234` — двоеточие в логинах не принимается. Запросите scope `profile` (логин возьмётся из `preferred_username`) или включите `extendedusernamechars`.
В Odoo кнопка провайдера есть, но вход отвечает отказом в доступе без подробностей	В модуле OIDC не хватает библиотеки `python-jose`: её импорт обёрнут в тихую ветку с записью только в отладочный лог. Модуль при этом ставится и выглядит рабочим.
В Odoo вместо возврата на сайт открывается голая страница ошибки	Настроен штатный модуль `auth_oauth`, который умеет только implicit flow. См. строку `unsupported_response_type` выше.

Записи в логе при старте

Симптом	Причина и что делать
При первом старте на пустой базе PostgreSQL — запись `Error` в категории `Microsoft.EntityFrameworkCore.Database.Command`: `Failed executing DbCommand … SELECT "MigrationId", "ProductVersion" FROM "__EFMigrationsHistory"`, а в логе PostgreSQL — `relation "__EFMigrationsHistory" does not exist`. Если журнал аудита тоже хранится в базе — у отдельного сервера он по умолчанию делит базу транзакций, — следом идёт вторая такая запись про его собственную таблицу истории, `__AuditTrailMigrationsHistory`. При включённом хранилище собранных claims — ещё одна, про `__CollectedClaimsMigrationsHistory`, в том числе на первом старте после включения хранилища на уже работающей базе	Штатное поведение, чинить нечего. Перед применением миграций EF Core читает свою таблицу истории миграций; на пустой базе её ещё нет, и отказ EF Core пишет в лог уровнем `Error`. Затем он создаёт таблицу и применяет миграции — старт продолжается, проверки здоровья зеленеют. При следующих стартах на той же базе этих записей нет. Если какая-то повторяется на каждом старте или старт не завершается — это настоящая ошибка: проверьте строку подключения и права пользователя базы.

Логи плагина на стороне приложения часто полезнее логов Veriqa: отказ, случившийся после успешного обмена кода на токены, в логах Veriqa выглядит как штатный вход. Если у Veriqa всё зелёное, а пользователь не вошёл — причина почти наверняка на стороне движка.