chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
aa4f487df3
commit
e48dd0d46f
File diff suppressed because it is too large
Load Diff
@ -1,20 +1,20 @@
|
||||
---
|
||||
read_when:
|
||||
- Налаштування контролю доступу до особистих повідомлень
|
||||
- Сполучення нового вузла iOS/Android
|
||||
- Створення пари з новим iOS/Android Node
|
||||
- Огляд стану безпеки OpenClaw
|
||||
summary: 'Огляд спарювання: схваліть, хто може надсилати вам приватні повідомлення + які вузли можуть приєднуватися'
|
||||
summary: 'Огляд сполучення: схвалюйте, хто може писати вам у приватні повідомлення + які вузли можуть приєднуватися'
|
||||
title: Сполучення
|
||||
x-i18n:
|
||||
generated_at: "2026-04-29T05:57:19Z"
|
||||
generated_at: "2026-05-01T22:59:51Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: cfdcaf831aedb122ea85200518b8dc1c6f42eff365444dee6c4b740050b1ce26
|
||||
source_hash: b11f4b538b9100e14c3dfe13c7a64995e5cebfc1c459839c6fa7a397f4cfb9ec
|
||||
source_path: channels/pairing.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
«Сполучення» — це явний крок підтвердження доступу в OpenClaw.
|
||||
«Сполучення» — це явний етап схвалення доступу в OpenClaw.
|
||||
Воно використовується у двох місцях:
|
||||
|
||||
1. **Сполучення DM** (кому дозволено спілкуватися з ботом)
|
||||
@ -22,97 +22,123 @@ x-i18n:
|
||||
|
||||
Контекст безпеки: [Безпека](/uk/gateway/security)
|
||||
|
||||
## 1) Сполучення DM (вхідний доступ до чату)
|
||||
## 1) Сполучення DM (доступ до вхідного чату)
|
||||
|
||||
Коли канал налаштовано з політикою DM `pairing`, невідомі відправники отримують короткий код, а їхнє повідомлення **не обробляється**, доки ви не схвалите доступ.
|
||||
|
||||
Типові політики DM задокументовано тут: [Безпека](/uk/gateway/security)
|
||||
Стандартні політики DM задокументовано тут: [Безпека](/uk/gateway/security)
|
||||
|
||||
`dmPolicy: "open"` є публічною лише тоді, коли ефективний список дозволених DM містить `"*"`.
|
||||
Налаштування й перевірка вимагають цей wildcard для публічно відкритих конфігурацій. Якщо наявний
|
||||
стан містить `open` з конкретними записами `allowFrom`, runtime все одно допускає
|
||||
лише цих відправників, а схвалення в pairing-store не розширюють доступ `open`.
|
||||
Налаштування й перевірка потребують цього wildcard для публічно відкритих конфігурацій. Якщо наявний
|
||||
стан містить `open` із конкретними записами `allowFrom`, під час виконання все одно допускаються
|
||||
лише ці відправники, а схвалення зі сховища сполучення не розширюють доступ `open`.
|
||||
|
||||
Коди сполучення:
|
||||
|
||||
- 8 символів, великі літери, без неоднозначних символів (`0O1I`).
|
||||
- **Завершують дію через 1 годину**. Бот надсилає повідомлення про сполучення лише коли створюється новий запит (приблизно раз на годину для кожного відправника).
|
||||
- Очікувані запити на сполучення DM типово обмежено **3 на канал**; додаткові запити ігноруються, доки один із них не завершить дію або не буде схвалений.
|
||||
- **Спливають через 1 годину**. Бот надсилає повідомлення про сполучення лише тоді, коли створюється новий запит (приблизно раз на годину для кожного відправника).
|
||||
- Очікувані запити сполучення DM за замовчуванням обмежено **3 на канал**; додаткові запити ігноруються, доки один із них не спливе або не буде схвалений.
|
||||
|
||||
### Схвалення відправника
|
||||
### Схвалити відправника
|
||||
|
||||
```bash
|
||||
openclaw pairing list telegram
|
||||
openclaw pairing approve telegram <CODE>
|
||||
```
|
||||
|
||||
Якщо власника команд ще не налаштовано, схвалення коду сполучення DM також початково заповнює
|
||||
`commands.ownerAllowFrom` схваленим відправником, наприклад `telegram:123456789`.
|
||||
Це дає початковим налаштуванням явного власника для привілейованих команд і запитів
|
||||
підтвердження exec. Після появи власника подальші схвалення сполучення надають лише
|
||||
доступ до DM; вони не додають нових власників.
|
||||
Якщо власника команд ще не налаштовано, схвалення коду сполучення DM також початково
|
||||
заповнює `commands.ownerAllowFrom` схваленим відправником, наприклад `telegram:123456789`.
|
||||
Це дає першому налаштуванню явного власника для привілейованих команд і запитів
|
||||
схвалення виконання. Після появи власника подальші схвалення сполучення надають лише
|
||||
доступ DM; вони не додають більше власників.
|
||||
|
||||
Підтримувані канали: `bluebubbles`, `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"` і перелічують учасників у звичайному для кожного каналу синтаксисі `allowFrom`.
|
||||
|
||||
```json5
|
||||
{
|
||||
accessGroups: {
|
||||
operators: {
|
||||
type: "message.senders",
|
||||
members: {
|
||||
"*": ["global-owner-id"],
|
||||
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`
|
||||
- Обліковий запис за замовчуванням: `<channel>-allowFrom.json`
|
||||
- Обліковий запис не за замовчуванням: `<channel>-<accountId>-allowFrom.json`
|
||||
|
||||
Поведінка області дії облікового запису:
|
||||
Поведінка областей дії облікових записів:
|
||||
|
||||
- Нетипові облікові записи читають/записують лише свій scoped файл списку дозволених.
|
||||
- Типовий обліковий запис використовує channel-scoped unscoped файл списку дозволених.
|
||||
- Облікові записи не за замовчуванням читають/записують лише свій файл списку дозволених з областю дії.
|
||||
- Обліковий запис за замовчуванням використовує файл списку дозволених каналу без області дії.
|
||||
|
||||
Ставтеся до них як до чутливих даних (вони керують доступом до вашого асистента).
|
||||
|
||||
<Note>
|
||||
Сховище списку дозволених для сполучення призначене для доступу до DM. Авторизація груп є окремою.
|
||||
Сховище списку дозволених для сполучення призначене для доступу DM. Авторизація груп є окремою.
|
||||
Схвалення коду сполучення DM не дозволяє цьому відправнику автоматично виконувати групові
|
||||
команди або керувати ботом у групах. Початкове налаштування першого власника є окремим станом конфігурації
|
||||
в `commands.ownerAllowFrom`, а доставка групових чатів і надалі дотримується
|
||||
списків дозволених груп каналу (наприклад `groupAllowFrom`, `groups` або перевизначень для окремих груп
|
||||
чи окремих тем залежно від каналу).
|
||||
команди або керувати ботом у групах. Початкове встановлення першого власника — це окремий стан
|
||||
конфігурації в `commands.ownerAllowFrom`, а доставка групового чату все одно дотримується
|
||||
групових списків дозволених каналу (наприклад `groupAllowFrom`, `groups` або перевизначень
|
||||
для окремої групи чи теми залежно від каналу).
|
||||
</Note>
|
||||
|
||||
## 2) Сполучення пристрою Node (iOS/Android/macOS/headless вузли)
|
||||
## 2) Сполучення пристроїв Node (iOS/Android/macOS/headless Node)
|
||||
|
||||
Вузли підключаються до Gateway як **пристрої** з `role: node`. Gateway
|
||||
Node підключаються до Gateway як **пристрої** з `role: node`. Gateway
|
||||
створює запит на сполучення пристрою, який потрібно схвалити.
|
||||
|
||||
### Сполучення через Telegram (рекомендовано для iOS)
|
||||
|
||||
Якщо ви використовуєте Plugin `device-pair`, перше сполучення пристрою можна повністю виконати з Telegram:
|
||||
|
||||
1. У Telegram напишіть вашому боту: `/pair`
|
||||
2. Бот відповідає двома повідомленнями: повідомленням з інструкцією та окремим повідомленням із **кодом налаштування** (його легко скопіювати/вставити в Telegram).
|
||||
3. На телефоні відкрийте застосунок OpenClaw iOS → Settings → Gateway.
|
||||
4. Вставте код налаштування та підключіться.
|
||||
5. Поверніться в Telegram: `/pair pending` (перегляньте ідентифікатори запитів, роль і області дії), потім схваліть.
|
||||
1. У Telegram напишіть своєму боту: `/pair`
|
||||
2. Бот відповість двома повідомленнями: повідомленням з інструкцією та окремим повідомленням із **кодом налаштування** (його легко скопіювати/вставити в Telegram).
|
||||
3. На телефоні відкрийте застосунок OpenClaw для iOS → Settings → Gateway.
|
||||
4. Вставте код налаштування й підключіться.
|
||||
5. Поверніться в Telegram: `/pair pending` (перегляньте ID запитів, роль і області дії), потім схваліть.
|
||||
|
||||
Код налаштування — це JSON-пакет, закодований у base64, який містить:
|
||||
Код налаштування — це JSON-навантаження, закодоване в base64, яке містить:
|
||||
|
||||
- `url`: WebSocket URL Gateway (`ws://...` або `wss://...`)
|
||||
- `bootstrapToken`: короткочасний bootstrap-токен для одного пристрою, який використовується для початкового handshake сполучення
|
||||
- `url`: URL WebSocket для Gateway (`ws://...` або `wss://...`)
|
||||
- `bootstrapToken`: короткочасний bootstrap-токен для одного пристрою, що використовується для початкового рукостискання сполучення
|
||||
|
||||
Цей bootstrap-токен несе вбудований bootstrap-профіль сполучення:
|
||||
|
||||
- основний переданий токен `node` залишається з `scopes: []`
|
||||
- будь-який переданий токен `operator` залишається обмеженим bootstrap-списком дозволених:
|
||||
`operator.approvals`, `operator.read`, `operator.talk.secrets`, `operator.write`
|
||||
- перевірки bootstrap-областей мають префікс ролі, а не один плаский пул областей:
|
||||
записи області operator задовольняють лише запити operator, а не-operator ролі
|
||||
все одно мають запитувати області під власним префіксом ролі
|
||||
- подальша ротація/відкликання токена залишається обмеженою як схваленим
|
||||
рольовим контрактом пристрою, так і operator-областями сесії викликача
|
||||
- перевірки bootstrap-областей дії мають префікс ролі, а не один плаский пул областей дії:
|
||||
записи областей дії operator задовольняють лише запити operator, а ролі не-operator
|
||||
все одно мають запитувати області дії з власним префіксом ролі
|
||||
- подальша ротація/відкликання токенів залишається обмеженою як схваленим
|
||||
контрактом ролі пристрою, так і областями дії operator сесії викликача
|
||||
|
||||
Ставтеся до коду налаштування як до пароля, доки він чинний.
|
||||
|
||||
### Схвалення пристрою Node
|
||||
### Схвалити пристрій Node
|
||||
|
||||
```bash
|
||||
openclaw devices list
|
||||
@ -120,18 +146,18 @@ openclaw devices approve <requestId>
|
||||
openclaw devices reject <requestId>
|
||||
```
|
||||
|
||||
Якщо той самий пристрій повторює спробу з іншими деталями автентифікації (наприклад іншими
|
||||
роллю/областями/публічним ключем), попередній очікуваний запит замінюється і створюється новий
|
||||
Якщо той самий пристрій повторює спробу з іншими даними автентифікації (наприклад іншими
|
||||
роллю/областями дії/публічним ключем), попередній очікуваний запит замінюється, і створюється новий
|
||||
`requestId`.
|
||||
|
||||
<Note>
|
||||
Уже сполучений пристрій не отримує ширший доступ непомітно. Якщо він повторно підключається і просить більше областей або ширшу роль, OpenClaw залишає наявне схвалення без змін і створює новий очікуваний запит на підвищення доступу. Використовуйте `openclaw devices list`, щоб порівняти поточний схвалений доступ із новим запитаним доступом перед схваленням.
|
||||
Уже сполучений пристрій не отримує ширший доступ непомітно. Якщо він повторно підключається, запитуючи більше областей дії або ширшу роль, OpenClaw залишає наявне схвалення без змін і створює новий очікуваний запит на підвищення доступу. Використовуйте `openclaw devices list`, щоб порівняти поточний схвалений доступ із новим запитаним доступом перед схваленням.
|
||||
</Note>
|
||||
|
||||
### Необов’язкове автоматичне схвалення Node за довіреним CIDR
|
||||
### Необов’язкове автоматичне схвалення Node для довірених CIDR
|
||||
|
||||
Сполучення пристроїв типово залишається ручним. Для суворо контрольованих мереж Node
|
||||
можна ввімкнути автоматичне схвалення першого підключення Node з явними CIDR або точними IP:
|
||||
Сполучення пристроїв за замовчуванням залишається ручним. Для суворо контрольованих мереж Node
|
||||
можна ввімкнути автоматичне схвалення першого Node з явними CIDR або точними IP-адресами:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -145,29 +171,29 @@ openclaw devices reject <requestId>
|
||||
}
|
||||
```
|
||||
|
||||
Це застосовується лише до нових запитів на сполучення `role: node` без запитаних
|
||||
областей. Клієнти Operator, браузера, Control UI та WebChat усе одно потребують ручного
|
||||
схвалення. Зміни ролі, області, метаданих і публічного ключа також потребують ручного
|
||||
Це застосовується лише до нових запитів сполучення `role: node` без запитаних
|
||||
областей дії. Клієнти operator, browser, Control UI та WebChat усе ще потребують ручного
|
||||
схвалення. Зміни ролі, області дії, метаданих і публічного ключа також потребують ручного
|
||||
схвалення.
|
||||
|
||||
### Зберігання стану сполучення Node
|
||||
|
||||
Зберігається в `~/.openclaw/devices/`:
|
||||
|
||||
- `pending.json` (короткочасний; очікувані запити завершують дію)
|
||||
- `pending.json` (короткочасний; очікувані запити спливають)
|
||||
- `paired.json` (сполучені пристрої + токени)
|
||||
|
||||
### Примітки
|
||||
|
||||
- Застарілий API `node.pair.*` (CLI: `openclaw nodes pending|approve|reject|remove|rename`) є
|
||||
окремим сховищем сполучення, власником якого є Gateway. WS-вузли все одно потребують сполучення пристрою.
|
||||
- Запис сполучення є довговічним джерелом істини для схвалених ролей. Активні
|
||||
окремим сховищем сполучення, яким володіє Gateway. WS Node все ще потребують сполучення пристроїв.
|
||||
- Запис сполучення є довготривалим джерелом істини для схвалених ролей. Активні
|
||||
токени пристроїв залишаються обмеженими цим схваленим набором ролей; випадковий запис токена
|
||||
поза схваленими ролями не створює нового доступу.
|
||||
|
||||
## Пов’язані документи
|
||||
|
||||
- Модель безпеки + prompt injection: [Безпека](/uk/gateway/security)
|
||||
- Модель безпеки + ін’єкція в prompt: [Безпека](/uk/gateway/security)
|
||||
- Безпечне оновлення (запустіть doctor): [Оновлення](/uk/install/updating)
|
||||
- Конфігурації каналів:
|
||||
- Telegram: [Telegram](/uk/channels/telegram)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user