Авторизация backend

Подготовьте обработчик

Авторизация нужна для действий приложения. Сначала опишите разрешённые операции в OpenAPI.

Как авторизуется backend приложения

MCP-ключ или OAuth-токен авторизует AI-клиент только в Senler. Senler проверяет проект, текущие права, активную установку и наличие точного действия в OpenAPI. Исходный MCP-секрет, OAuth-токен или заголовок авторизации не передаются в backend плагина.

Вместо этого для каждого вызова создаётся короткая сессия между Senler и приложением:

Senler подписывает одноразовый launch_code с ID проекта, сроком действия и nonce с помощью Client Secret приложения;
отправляет его на /api/embedded/management-session того же origin, где размещён OpenAPI;
backend проверяет подпись, срок и повтор nonce, затем возвращает собственный короткоживущий management_token;
Senler вызывает отмеченный endpoint с Authorization: Bearer <management_token>.

Запрос создания сессии выглядит так:

POST /api/embedded/management-session
Content-Type: application/json

{"launch_code":"<одноразовый код Senler>"}

Backend приложения должен проверить launch_code с Client Secret и вернуть собственный короткоживущий токен:

{"management_token":"app-session-token"}

Создание management session должно завершиться за 5 секунд, ответ с токеном ограничен 64 КиБ. Тайм-аут одного действия — 15 секунд; размер его ответа ограничен 5 МиБ, а для отчёта воронки — 2 МиБ. Перенаправления не выполняются. Определяйте проект и права только по проверенной management session, а не по параметрам, которые AI передал методу.

management_token действует только в backend самого приложения. Если backend после этого вызывает API Senler, ему нужен собственный API-ключ или OAuth access token приложения с нужными правами. Ни management_token, ни исходный MCP-токен для API Senler не подходят.