Перейти к содержимому

ДОКУМЕНТАЦИЯ

Учётные данные, Runtime Token и OAuth в OpenConnector

Настройте учётные данные сервисов, доступ к runtime, обратные вызовы OAuth и именованные подключения в собственном OpenConnector.

Поддерживает OOMOL·

Исходный код проверен 2026-09-09. Примеры сверены с указанной ревизией исходного кода. Это не подтверждение проверки реального API сервиса; ваша версия может отличаться.

Доступ к runtime и учётные данные сервиса

Учётные данные администратора защищают консоль и /api. Runtime Token разрешает обращения клиентов к /v1 и /mcp. Учётные данные сервиса принадлежат подключённому аккаунту и остаются внутри runtime. Эти данные не взаимозаменяемы.

Зарегистрируйте своё OAuth-приложение

При самостоятельном размещении зарегистрируйте OAuth-приложение у провайдера и скопируйте точный expectedRedirectUri из /api/oauth/configs. Перед настройкой внешнего обратного вызова задайте публичный origin в OOMOL_CONNECT_ORIGIN. Выбирайте нужные для работы разрешения.

Выберите подключение аккаунта

Без псевдонима используется подключение провайдера по умолчанию. Именованное подключение задаётся через x-oo-connector-alias. Права Runtime Token могут ограничивать доступные клиенту аккаунты.

Сохраняйте и защищайте учётные данные

Образ Docker использует /app/data для локальных данных runtime. Подключите постоянный том. Настройте OOMOL_CONNECT_ENCRYPTION_KEY для шифрования учётных данных и сохраните ключ для восстановления. Перед публикацией runtime изучите руководство по развёртыванию.

Завершите подключение OAuth

  1. Сначала задайте в OOMOL_CONNECT_ORIGIN адрес, используемый браузером. Прочитайте /api/oauth/configs и точно скопируйте expectedRedirectUri нужного провайдера в OAuth-приложение. При включённой защите администрирования добавьте Bearer-токен администратора.
  2. В локальной консоли сохраните Client ID и Secret OAuth-приложения. При необходимости выберите часть объявленных провайдером scopes, начните авторизацию и разрешите доступ на странице провайдера в браузере.
  3. После callback проверьте /api/connections: аккаунт и имя подключения должны соответствовать задаче. Именованное подключение должно существовать заранее; указание псевдонима не создаёт его.

Первый запрос ниже проверяет подключения с токеном администратора. Второй вызывает Action только для чтения с токеном runtime и существующим подключением work. Укажите своё имя подключения; для подключения по умолчанию уберите заголовок псевдонима.

GET /api/connections
curl -s http://localhost:3000/api/connections \
  -H "Authorization: Bearer $OOMOL_CONNECT_ADMIN_TOKEN"
HTTP · GitHub
curl -s -X POST \
  http://localhost:3000/v1/actions/github.get_current_user \
  -H "Authorization: Bearer $OOMOL_CONNECT_RUNTIME_TOKEN" \
  -H 'x-oo-connector-alias: work' \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

Как читать результат

Ответы HTTP runtime содержат success, message, data и meta. Проверяйте success и выходную схему Action, а не только HTTP-статус. Если метаданные содержат executionId, по нему можно найти журнал с замаскированными секретами. Ниже показан формат ответа, а не результат реального вызова API.

Пример формата ответа
{
  "success": true,
  "message": "OK",
  "data": {},
  "meta": {}
}

Если вызов не удался

  • При ошибке аутентификации проверьте адрес и тип учётных данных: административный доступ защищает /api, Bearer-токен runtime используется для /v1 и /mcp. API-ключ провайдера не заменяет токен runtime.
  • При отказе в доступе проверьте scopes Action, правила Actions и разрешения на подключения. Даже действительный токен может не иметь доступа к выбранному аккаунту.
  • Если результат пуст или ресурс отсутствует, проверьте аккаунт и его права на этот ресурс. Успешная авторизация не открывает все рабочие пространства, каналы и документы.
  • Изучите ошибку и журнал до повтора. Если Action изменяет данные провайдера, сначала проверьте, не завершилась ли операция; не повторяйте запрос вслепую.
Читать в Markdown