Перейти до основного вмісту

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

“Сполучення” є явним кроком OpenClaw для підтвердження доступу. Воно використовується у двох місцях:
  1. Сполучення DM (кому дозволено спілкуватися з ботом)
  2. Сполучення Node (яким пристроям/Node дозволено приєднуватися до мережі Gateway)
Контекст безпеки: Безпека

​
1) Сполучення DM (вхідний доступ до чату)

Коли канал налаштовано з політикою DM pairing, невідомі відправники отримують короткий код, а їхнє повідомлення не обробляється, доки ви не надасте підтвердження. Типові політики DM задокументовано тут: Безпека dmPolicy: "open" є публічною лише тоді, коли ефективний список дозволених DM містить "*". Налаштування й перевірка потребують цього wildcard для публічно відкритих конфігурацій. Якщо наявний стан містить open із конкретними записами allowFrom, під час виконання все одно допускаються лише ці відправники, а підтвердження в сховищі сполучень не розширюють доступ open. Коди сполучення:
  • 8 символів, великі літери, без неоднозначних символів (0O1I).
  • Закінчуються через 1 годину. Бот надсилає повідомлення про сполучення лише тоді, коли створюється новий запит (приблизно раз на годину для кожного відправника).
  • Очікувані запити на сполучення DM типово обмежені 3 на канал; додаткові запити ігноруються, доки один із них не закінчиться або не буде підтверджений.

​
Підтвердити відправника

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>
Якщо власника команд ще не налаштовано, підтвердження коду сполучення DM також ініціалізує commands.ownerAllowFrom для підтвердженого відправника, наприклад telegram:123456789. Це дає першому налаштуванню явного власника для привілейованих команд і запитів на підтвердження exec. Після появи власника наступні підтвердження сполучення надають лише доступ DM; вони не додають нових власників. Підтримувані канали: discord, feishu, googlechat, imessage, irc, line, matrix, mattermost, msteams, nextcloud-talk, nostr, openclaw-weixin, signal, slack, synology-chat, telegram, twitch, whatsapp, zalo, zalouser.

​
Багаторазові групи відправників

Використовуйте верхньорівневі accessGroups, коли той самий набір довірених відправників має застосовуватися до кількох каналів повідомлень або одночасно до списків дозволених DM і груп. Статичні групи використовують type: "message.senders" і на них посилаються через accessGroup:<name> зі списків дозволених каналів: 
{
  accessGroups: {
    operators: {
      type: "message.senders",
      members: {
        discord: ["discord:123456789012345678"],
        telegram: ["987654321"],
        whatsapp: ["+15551234567"],
      },
    },
  },
  channels: {
    telegram: { dmPolicy: "allowlist", allowFrom: ["accessGroup:operators"] },
    whatsapp: { groupPolicy: "allowlist", groupAllowFrom: ["accessGroup:operators"] },
  },
}
Групи доступу докладно задокументовано тут: Групи доступу

​
Де зберігається стан

Зберігається в ~/.openclaw/credentials/:
  • Очікувані запити: <channel>-pairing.json
  • Сховище підтвердженого списку дозволених:
    • Типовий обліковий запис: <channel>-allowFrom.json
    • Не типовий обліковий запис: <channel>-<accountId>-allowFrom.json
Поведінка прив’язки до облікового запису:
  • Не типові облікові записи читають/записують лише свій файл списку дозволених.
  • Типовий обліковий запис використовує не прив’язаний до облікового запису файл списку дозволених каналу.
Вважайте ці дані чутливими (вони контролюють доступ до вашого асистента).
Сховище списку дозволених для сполучення призначене для доступу DM. Авторизація груп є окремою. Підтвердження коду сполучення DM не надає цьому відправнику автоматичного дозволу виконувати групові команди або керувати ботом у групах. Початкова ініціалізація першого власника є окремим станом конфігурації в commands.ownerAllowFrom, а доставка групових чатів і надалі дотримується списків дозволених груп каналу (наприклад groupAllowFrom, groups або перевизначень для окремих груп чи тем, залежно від каналу).

​
2) Сполучення пристроїв Node (iOS/Android/macOS/headless Node)

Nodes підключаються до Gateway як пристрої з role: node. Gateway створює запит на сполучення пристрою, який потрібно підтвердити.

​
Сполучення через Telegram (рекомендовано для iOS)

Якщо ви використовуєте Plugin device-pair, перше сполучення пристрою можна повністю виконати з Telegram:
  1. У Telegram напишіть своєму боту: /pair
  2. Бот відповідає двома повідомленнями: повідомленням з інструкціями й окремим повідомленням із кодом налаштування (його легко скопіювати/вставити в Telegram).
  3. На телефоні відкрийте застосунок OpenClaw для iOS → Налаштування → Gateway.
  4. Відскануйте QR-код або вставте код налаштування й підключіться.
  5. Поверніться в Telegram: /pair pending (перегляньте ID запитів, роль і scopes), потім підтвердьте.
Код налаштування — це закодоване в base64 JSON-навантаження, яке містить:
  • url: URL WebSocket Gateway (ws://... або wss://...)
  • bootstrapToken: короткочасний bootstrap-токен для одного пристрою, який використовується для початкового handshake сполучення
Цей bootstrap-токен містить вбудований bootstrap-профіль сполучення:
  • основний переданий токен node лишається scopes: []
  • будь-який переданий токен operator лишається обмеженим bootstrap-списком дозволених: operator.approvals, operator.read, operator.talk.secrets, operator.write
  • перевірки bootstrap scopes мають префікс ролі, а не один плаский пул scopes: записи scope оператора задовольняють лише запити оператора, а неоператорські ролі все одно мають запитувати scopes під власним префіксом ролі
  • подальша ротація/відкликання токенів лишається обмеженою як підтвердженим контрактом ролі пристрою, так і operator scopes сеансу викликача
Ставтеся до коду налаштування як до пароля, доки він чинний. Для Tailscale, публічного або іншого віддаленого мобільного сполучення використовуйте Tailscale Serve/Funnel або інший URL Gateway wss://. Відкриті текстові коди налаштування ws:// приймаються лише для loopback, приватних адрес LAN, хостів Bonjour .local і хоста емулятора Android. Адреси Tailnet CGNAT, імена .ts.net і публічні хости все одно закриваються з помилкою до видачі QR/коду налаштування.

​
Підтвердити пристрій Node

openclaw devices list
openclaw devices approve <requestId>
openclaw devices reject <requestId>
Коли явне підтвердження відхилено, бо сеанс сполученого пристрою, який підтверджує, було відкрито лише зі scope сполучення, CLI повторює той самий запит із operator.admin. Це дає наявному сполученому пристрою з можливостями адміністратора змогу відновити нове сполучення Control UI/браузера без ручного редагування devices/paired.json. Gateway все одно перевіряє повторне підключення; токени, які не можуть автентифікуватися з operator.admin, залишаються заблокованими. Якщо той самий пристрій повторює спробу з іншими даними автентифікації (наприклад іншими role/scopes/public key), попередній очікуваний запит замінюється, і створюється новий requestId.
Уже сполучений пристрій не отримує ширшого доступу непомітно. Якщо він перепідключається із запитом на більше scopes або ширшу роль, OpenClaw зберігає наявне підтвердження без змін і створює новий очікуваний запит на підвищення доступу. Використовуйте openclaw devices list, щоб порівняти поточний підтверджений доступ із новим запитаним доступом перед підтвердженням.

​
Необов’язкове автоматичне підтвердження Node за довіреними CIDR

За замовчуванням сполучення пристроїв лишається ручним. Для суворо контрольованих мереж Node можна явно ввімкнути автоматичне підтвердження першого сполучення Node за CIDR або точними IP: 
{
  gateway: {
    nodes: {
      pairing: {
        autoApproveCidrs: ["192.168.1.0/24"],
      },
    },
  },
}
Це застосовується лише до нових запитів на сполучення role: node без запитаних scopes. Клієнти Operator, браузера, Control UI та WebChat все одно потребують ручного підтвердження. Зміни ролі, scope, metadata і public-key також потребують ручного підтвердження.

​
Зберігання стану сполучення Node

Зберігається в ~/.openclaw/devices/:
  • pending.json (короткочасний; очікувані запити закінчуються)
  • paired.json (сполучені пристрої + токени)

​
Примітки

  • Застарілий API node.pair.* (CLI: openclaw nodes pending|approve|reject|remove|rename) є окремим сховищем сполучень, яким володіє Gateway. WS Nodes все одно потребують сполучення пристрою.
  • Запис сполучення є тривалим джерелом істини для підтверджених ролей. Активні токени пристроїв лишаються обмеженими цим підтвердженим набором ролей; випадковий запис токена поза підтвердженими ролями не створює нового доступу.

​
Пов’язані документи