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

# Helio — поддержка клиентов

> Пример-витрина, изображающий раздел поддержки на сайте: публичная страница, вход, карточка клиента и степ-ап перед закрытием или удалением обращения.

Helio — запускаемый эмулятор целого продукта, а не одного механизма: раздел поддержки на сайте
вымышленной компании. В нём связано воедино то, что делает обычный веб-продукт, — страница, которую
может читать любой, вход, данные человека и подтверждение перед действием, которое имеет значение, —
чтобы сценарии было видно от начала до конца так, как их встречает клиент.

`samples/dotnet/showcase/support-desk` · `https://localhost:7360`

<Note>
  Страница поддержки принадлежит вымышленной компании. Страница входа и окно подтверждения —
  собственные экраны Veriqa, показанные как есть: через `AuthPageDesign` заданы только название
  бренда, логотип, основной цвет и то, что QR-код показывается лишь на десктопе.
</Note>

## Что видит клиент

<Steps>
  <Step title="Публичная страница">
    Раздел поддержки доступен для чтения любому; никого не перенаправляют при заходе.
  </Step>

  <Step title="Вход">
    Посетитель уходит на страницу входа Veriqa и возвращается узнанным: на десктопе — по QR-коду, на
    телефоне — кнопкой канала. Вход не просит контактов.
  </Step>

  <Step title="Карточка клиента">
    Карточка собирается из claims, которые дал канал: отображаемое имя, имя и фамилия, аватар,
    `@username` и замаскированный ID (Telegram). Телефон или адрес появляется, только когда клиент
    его подтвердил. Рядом — обращения клиента.
  </Step>

  <Step title="Контакт, когда он понадобился">
    «Call me back» и «Answer by e-mail» открываются, когда клиент подтвердил номер телефона или адрес
    email, — каждый ещё одним authorize-запросом. Запрос добавляет scope и называет claim
    обязательным в параметре `claims`, а приложение принимает значение только вместе с признаком
    `*_verified`. См. [Постепенное обогащение профиля](/docs/ru/concepts/claim-enrichment).
  </Step>

  <Step title="Степ-ап">
    Закрытие или удаление обращения подтверждается в канале, **этим же человеком**. Диалог на
    странице лишь защищает от случайного клика; решает вопрос в канале.
  </Step>
</Steps>

Два сценария оставляют в чате разные квитанции. Вопрос входа заменяется на
«Sign-in to Helio Support confirmed ✅» (`ReplacePrompt`); действие с обращением сохраняет свой
вопрос и получает квитанцию отдельным сообщением (`NewMessage`, задан в записи клиента бэкенда), так
что одобренное остаётся читаемым. См. `OutcomeNotice` в [Конфигурации](/docs/ru/reference/configuration).

## Как он устроен

Один процесс играет три роли:

| Роль | Что это |
| - | - |
| Встроенный издатель Veriqa | `AddVeriqaAuthServer` → `UseVeriqaAuthServer` → `MapVeriqaAuthServer` |
| OIDC-клиент браузера | штатный обработчик `AddOpenIdConnect`, направленный на этот же процесс |
| Бэкенд, создающий подтверждения | `VeriqaConfirmationClient`, вызывающий [API серверного подтверждения](/docs/ru/reference/confirmation-api) по HTTP |

**Степ-ап, адресованный вошедшему.** Закрытие и удаление обращения — два объявленных типа действий,
`resolve-ticket` и `delete-ticket`, каждый со своей формулировкой. Каждое подтверждение называет одну
ожидаемую личность — ту, что принадлежит каналу, через который пришла текущая сессия
(`expected_identities`), — и операция применяется, только если совпал `matched_type`: подтверждение
с другого аккаунта, как и отказ или истечение срока, оставляет обращение нетронутым. На какое
обращение действует транзакция, запоминается на сервере, поэтому ни один браузер не может удалить
одно обращение, подтвердив другое.

**Идентификаторы остаются на сервере.** Полный ID пользователя в канале адресует степ-ап и в браузер
не уходит: ID пользователя и номер телефона маскируются до того, как попадут в ответ.

**Без базы данных.** Обращения синтезируются из claim `sub`, поэтому один и тот же человек при каждом
визите видит один и тот же список. В памяти хранится только то, какие обращения клиент закрыл или
удалил; перезапуск это забывает.

<Note>
  Этот степ-ап идёт через API серверного подтверждения. Другой путь — повторный authorize и проверка
  `auth_time` в браузере — описан в разделе
  [«Второй фактор, step-up и подтверждение действий»](/docs/ru/scenarios/step-up).
</Note>

## Запуск

Что нужно:

* .NET SDK 10.0+;
* доверенный сертификат разработки — приложение вызывает **само себя** по HTTPS:
  `dotnet dev-certs https --trust`;
* учётные данные хотя бы одного канала. Самый короткий путь — токен бота Telegram от
  [@BotFather](https://t.me/BotFather).

Каналы поставляются **выключенными с пустыми учётными данными**: канал, включённый без учётных
данных, валит старт. Включите те, что у вас есть, и запустите пример:

```bash theme={null}
dotnet user-secrets --project samples/dotnet/showcase/support-desk set "Veriqa:Channels:Telegram:BotToken" "<token>"
dotnet user-secrets --project samples/dotnet/showcase/support-desk set "Veriqa:Channels:Telegram:Enabled" "true"
dotnet run --project samples/dotnet/showcase/support-desk
```

Откройте `https://localhost:7360`. В примере подключены адаптеры Telegram, WhatsApp и Email; WhatsApp
и Email включаются так же — через их секции `Veriqa:Channels:WhatsApp:*` и `Veriqa:Channels:Email:*`
с `Enabled`, установленным в `true`. MAX в этот пример не входит: его пакет не подключён, а адаптер
не зарегистрирован. Страница входа предлагает ровно те каналы, что включены, — пустая страница входа
означает, что не включён ни один. Учётные данные каждого канала описаны в
[Настройке каналов](/docs/ru/guides/channels).

<Tip>
  Бот Telegram доставляет обновления на один адрес webhook, поэтому с одним токеном бота входы
  принимает только один из двух примеров-витрин одновременно.
</Tip>

Пример работает и за HTTP-туннелем — с Telegram в режиме `Webhook`. Какие переменные задать, API
страницы и подробности степ-апа — в `README.ru.md` примера в репозитории
([veriqa.app/source](https://veriqa.app/source), путь `samples/dotnet/showcase/support-desk`): он
остаётся подробным руководством по настройке.

## Видео

<CardGroup cols={2}>
  <Card title="Вход на десктопе" icon="desktop" href="/docs/ru/videos/desktop-sign-in">
    Вход по QR и карточка клиента из claims канала.
  </Card>

  <Card title="Вход на телефоне" icon="mobile" href="/docs/ru/videos/mobile-sign-in">
    Без QR-кода — кнопка канала открывает мессенджер на том же устройстве.
  </Card>

  <Card title="Step-up на десктопе" icon="desktop" href="/docs/ru/videos/desktop-step-up">
    Удаление обращения требует подтверждения в мессенджере.
  </Card>

  <Card title="Step-up на телефоне" icon="mobile" href="/docs/ru/videos/mobile-step-up">
    Закрытие обращения подтверждается в Telegram на том же устройстве.
  </Card>
</CardGroup>

## См. также

* [Примеры-витрины](/docs/ru/samples#примеры-витрины)
* [Второй фактор, step-up и подтверждение действий](/docs/ru/scenarios/step-up)
* [API серверного подтверждения](/docs/ru/reference/confirmation-api)
* [Вход и привязка канала одним действием](/docs/ru/scenarios/channel-linking)
* [Настройка каналов](/docs/ru/guides/channels)


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