Встроенная страница RefLink

Этот пример относится к плагину RefLink. Общий порядок подключения своей страницы описан во «Встроенной странице».

Как открывается страница

1. Пользователь открывает RefLink в проекте. Кабинет загружает frontend во встроенной странице и передаёт контекст запуска через Senler Bridge.
2. Frontend получает launch_code и project_id в useEmbeddedRefLinkApp.ts. Значение project_id нужно интерфейсу для проверки соответствия, но само по себе оно не даёт доступ.
3. Frontend отправляет одноразовый launch_code в POST /api/embedded/session.
4. Backend проверяет подпись, срок и одноразовость кода в backend/src/core/session, извлекает из него проект и выдаёт собственный session_token RefLink.
5. Все следующие запросы страницы используют этот session_token. EmbeddedSessionGuard снова извлекает проект из проверенной сессии, поэтому контроллерам не нужен project_id из формы или URL.
6. Если проект ещё не подключён по OAuth, frontend показывает AuthorizationStep. После согласия backend получает project-scoped OAuth-токены Senler и сохраняет их для этого проекта.
7. Для загрузки каналов, агентов, сегментов и автоматизаций backend берёт OAuth access token и вызывает API Senler через SenlerApiClient.

Итог: браузер знает только сессию RefLink, а доступ к API Senler и Client Secret остаются на backend.

Один frontend обслуживает несколько контекстов

Общая точка входа уменьшает дублирование авторизации, загрузки данных, стилей и компонентов. Разница между основной страницей и формой шага определяется не отдельным URL, а проверенным context.launch.type от Senler Bridge.

Если приложение добавит конфигуратор инструмента агента, эту схему можно расширить третьей явной веткой tool_configurator, не смешивая сохранение настроек с обычной работой страницы.

Сессия страницы, management session и OAuth-токен решают разные задачи. Не подменяйте один другим: их назначение приведено в схеме авторизации RefLink.