> ## 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.

# WordPress

> Вход в WordPress через Veriqa на штатном плагине openid-connect-generic: настройки, обязательный шаг со scope и то, какой получается учётная запись.

WordPress входит через Veriqa на **штатном** плагине — ни ядро Veriqa, ни его поставка под CMS
не меняются. Всё, что требуется, живёт на стороне сайта: плагин, его настройки и одна правка
формы запроса, о которой ниже.

<Note>
  Проверено: WordPress 6 + `openid-connect-generic` 3.11.3; канал Telegram. Работают вход,
  автоматическое создание пользователя, проверка подписи `id_token` по JWKS. Связка
  WordPress + Email/WhatsApp/MAX не проверялась.
</Note>

## Что понадобится

* развёрнутый сервер Veriqa с адресом, доступным сайту (в проде — публичный HTTPS с валидным
  сертификатом);
* зарегистрированный в Veriqa клиент: `client_id`, `client_secret` и `redirect_uri` вида
  `https://ваш-сайт/wp-admin/admin-ajax.php?action=openid-connect-authorize`;
* права администратора в WordPress.

Клиент должен быть **confidential** — с секретом. Такому клиенту Veriqa разрешает вход без PKCE,
и именно это делает возможной работу с коробочными плагинами CMS.

## 1. Плагин

Ставится `openid-connect-generic` (10k+ установок, поддерживается). Альтернативы не подходят:
`nicko170/wp-openid` не обновлялся с 2023 года, плагин Scouting прибит к чужому issuer,
miniOrange прячет нужные настройки в платной редакции.

## 2. Настройки плагина

Адреса берутся из discovery вашего сервера
(`https://veriqa.example.com/.well-known/openid-configuration`):

| Поле плагина | Значение |
| - | - |
| `endpoint_login` | `/connect/authorize` |
| `endpoint_token` | `/connect/token` |
| `endpoint_userinfo` | `/connect/userinfo` |
| `endpoint_jwks` | `/.well-known/jwks` |
| `client_id`, `client_secret` | из регистрации клиента |
| `scope` | `openid profile email` (плюс `channel`, если RP нужны типизированные claims канала) |

Четыре настройки стоит назвать отдельно — они определяют, как будет выглядеть учётная запись:

* **`identity_key` — не трогайте.** На дефолте логин получается человекочитаемым (`alice`);
  выставленный вручную `sub` даёт логин вида `telegram123456789`.
* **`nickname_key` → `preferred_username`**, **`displayname_format` → `name`**.
* **`enable_logging` — включите** хотя бы на время настройки: лог плагина сокращает разбор
  проблем с часов до минут.
* **`no_sslverify` — оставьте выключенным.** Проверка TLS должна работать; если она мешает,
  проблема в сертификате, а не в проверке.

## 3. Уберите `scope` из запроса обмена кода

Это обязательный шаг, и его стоит понять, а не просто выполнить.

Плагин кладёт `scope` в запрос `grant_type=authorization_code`, где
[RFC 6749 §4.1.3](https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3) его не предусматривает:
набор scope приходит из самого кода авторизации. Keycloak, Auth0 и Azure лишний параметр молча
игнорируют — строгий сервер на OpenIddict отвергает запрос (issue #1729 в OpenIddict закрыт как
*invalid*).

<Note>
  Снятие параметра делает запрос **соответствующим** стандарту. Это не обход проверки и не
  ослабление вашей безопасности: убирается то, чего в запросе быть не должно.
</Note>

Вариантов два, они взаимозаменяемы — **ставить оба не нужно**. Выбор зависит от того, чей это
участок: сайт или развёртывание Veriqa.

<CardGroup cols={2}>
  <Card title="Правит владелец сайта" icon="wordpress">
    mu-plugin в шесть строк на стороне WordPress. Сервер Veriqa не трогается — подходит, когда
    Veriqa вам не принадлежит (например, это облако или чужое развёртывание).
  </Card>

  <Card title="Правит владелец Veriqa" icon="server">
    Квирк совместимости `drop-scope-on-code-exchange` — послабление для одного `ClientId` на
    стороне сервера. Подходит, когда сайтов много, а лезть в каждый не хочется.
  </Card>
</CardGroup>

### Вариант А — mu-plugin

Положите файл в `wp-content/mu-plugins/` (создайте каталог, если его нет). Must-use плагины
включаются автоматически — активировать в админке ничего не нужно.

```php wp-content/mu-plugins/veriqa-oidc-compat.php theme={null}
<?php

/**
 * Plugin Name: Veriqa OIDC compatibility
 * Description: Убирает параметр scope из токен-запроса плагина OpenID Connect Generic.
 */

declare(strict_types=1);

add_filter(
    'openid-connect-generic-alter-request',
    static function (array $request, string $operation): array {
        if ('get-authentication-token' === $operation) {
            unset($request['body']['scope']);
        }

        return $request;
    },
    10,
    2
);
```

Правка хирургична: `scope` снимается только у операции `get-authentication-token`. У обновления
токена он остаётся — там RFC 6749 §6 сужение scope разрешает.

### Вариант Б — квирк на стороне Veriqa

Тот же параметр снимается сервером, для одного клиента. Включение двухступенчатое, и Veriqa
пишет о включённом квирке предупреждение в лог при старте:

```json appsettings.json theme={null}
{
  "Veriqa": {
    "OpenIddict": {
      "CompatibilityQuirksAllowApplicationOverride": true,
      "Clients": [
        {
          "ClientId": "wordpress-site",
          "CompatibilityQuirks": [ "drop-scope-on-code-exchange" ]
        }
      ]
    }
  }
}
```

Подробности, условие снятия и профиль `wordpress-openid-connect-generic` —
в [Совместимости с клиентами](/docs/ru/guides/client-compatibility).

Без любого из двух вариантов вход падает на обмене кода, и WordPress возвращает браузер на
`wp-login.php?login-error=invalid_request&message=…`.

## Что получится

В логе плагина — `login-success  Successful login for: telegram123456789`; от клика до входа
проходит порядка двадцати секунд, включая время, которое человек тратит на телефон. Пользователь
создаётся автоматически.

**Учётная запись создаётся с пустым email** — Telegram адреса не отдаёт и не отдаст. Если email
для вашего сайта обязателен, есть два пути: канал Email (тогда адрес приезжает в claims) или
запрос адреса самим WordPress после первого входа.

## Границы

* Проверено с каналом **Telegram**. На канале Email профиль выглядит иначе: `name` дублирует
  адрес, а не человекочитаемое имя, поэтому рецепт, отлаженный на Telegram, даст другой вид
  учётной записи.
* Отдельный плагин «Veriqa for WordPress» не нужен: штатный плагин закрывает задачу целиком.
* Аватар в этот рецепт не входит: `picture` — изображение в виде URI `data:`, выдаётся только по
  scope `avatar` и только через userinfo, а настройка плагина выше этот scope не запрашивает.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.