> ## Documentation Index > Fetch the complete documentation index at: https://veriqa.app/docs/llms.txt > Use this file to discover all available pages before exploring further. # Диагностика > Каталог ошибок интеграции: симптом, причина и что делать. Ищите симптом по тексту ошибки — большинство из них означает не то, что кажется на первый взгляд. ## Отказы на `/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 в рабочих системах](/docs/ru/integrations/apps). | | `invalid_target` · `ID2190` — `One of the specified 'resource' parameters is invalid` | Клиент шлёт параметр `resource` (индикаторы ресурса RFC 8707). Veriqa их не регистрирует, поэтому **любое** значение отвергается. Так ведёт себя плагин `auth_oidc` у Moodle, писанный под Microsoft Entra ID, — разбор на странице [Veriqa в рабочих системах](/docs/ru/integrations/apps). Для клиента, которому это не отключить, включите квирк уровня клиента [`drop-resource-parameter`](/docs/ru/guides/client-compatibility). | | `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](/docs/ru/integrations/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](/docs/ru/integrations/typo3). | | `No email address provided by ` в Drupal | Канал не отдал email, а Drupal требует его на **каждом** входе. Решение — на странице [Drupal](/docs/ru/integrations/drupal). | | WordPress возвращает на `wp-login.php?login-error=invalid_request` | Тот же лишний `scope` в обмене кода — см. [WordPress](/docs/ru/integrations/wordpress). | | В Битриксе вход всегда происходит под администратором | Фильтр `CUser::GetList` с D7-синтаксисом молча отброшен, и выбирается первый пользователь. Разбор — на странице [Битрикс](/docs/ru/integrations/bitrix). | | В Moodle «Error in OpenID Connect. Please check logs for more information.» | Moodle не пошёл до Veriqa вовсе: сработала его защита исходящих запросов — по адресу (`curlsecurityblockedhosts`) **или по порту** (`curlsecurityallowedport`, по умолчанию только 443 и 80). Настоящая причина (`The URL is blocked.`) видна лишь после включения `debugmode` у плагина. Порт блокируется и на публичном адресе — см. [Veriqa в рабочих системах](/docs/ru/integrations/apps). | | В 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](/docs/ru/guides/storage#хранилище-собранных-claims) — ещё одна, про `__CollectedClaimsMigrationsHistory`, в том числе на первом старте после включения хранилища на уже работающей базе | **Штатное поведение, чинить нечего.** Перед применением [миграций](/docs/ru/guides/storage) EF Core читает свою таблицу истории миграций; на пустой базе её ещё нет, и отказ EF Core пишет в лог уровнем `Error`. Затем он создаёт таблицу и применяет миграции — старт продолжается, проверки здоровья зеленеют. При следующих стартах на той же базе этих записей нет. Если какая-то повторяется на **каждом** старте или старт не завершается — это настоящая ошибка: проверьте строку подключения и права пользователя базы. | Логи плагина на стороне приложения часто полезнее логов Veriqa: отказ, случившийся **после** успешного обмена кода на токены, в логах Veriqa выглядит как штатный вход. Если у Veriqa всё зелёное, а пользователь не вошёл — причина почти наверняка на стороне движка. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.