openclaw/docs
openclaw/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(i18n): refresh uk translations

Browse Source
This commit is contained in:
openclaw-docs-i18n[bot] 2026-05-04 07:17:06 +00:00
parent 5234e8bc5b
commit 2bf8326873
1 changed files with 80 additions and 73 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

153
docs/uk/channels/pairing.md
View File

@ -1,43 +1,43 @@
---
read_when:
- Налаштування контролю доступу до особистих повідомлень
- Сполучення нового iOS/Android Node
- Налаштування контролю доступу до приватних повідомлень
- Сполучення нового вузла iOS/Android
- Огляд стану безпеки OpenClaw
summary: 'Огляд сполучення: схваліть, хто може писати вам у приватні повідомлення + які вузли можуть приєднуватися'
summary: 'Огляд сполучення: схвалюйте, хто може надсилати вам приватні повідомлення + які вузли можуть приєднуватися'
title: Сполучення
x-i18n:
generated_at: "2026-05-03T23:54:54Z"
generated_at: "2026-05-04T07:16:25Z"
model: gpt-5.5
provider: openai
source_hash: 4fb27840f7c9ef55e7270cc29f813e6db90b240aa2180f30952eb9485f0f8874
source_hash: f2bce4cfba7708b0003f2ffeacada8bc1849cc301f28178b499a9a67bddcf36d
source_path: channels/pairing.md
workflow: 16
---
«Створення пари» — це явний крок схвалення доступу в OpenClaw.
«Сполучення» — це явний крок схвалення доступу в OpenClaw.
Він використовується у двох місцях:
1. **Створення пари для DM** (кому дозволено спілкуватися з ботом)
2. **Створення пари з Node** (яким пристроям/Node дозволено приєднуватися до мережі Gateway)
1. **Сполучення DM** (кому дозволено спілкуватися з ботом)
2. **Сполучення Node** (яким пристроям/вузлам дозволено приєднуватися до мережі Gateway)
Контекст безпеки: [Безпека](/uk/gateway/security)
## 1) Створення пари для DM (вхідний доступ до чату)
## 1) Сполучення DM (вхідний доступ до чату)
Коли канал налаштовано з політикою DM `pairing`, невідомі відправники отримують короткий код, а їхнє повідомлення **не обробляється**, доки ви не схвалите доступ.
Стандартні політики DM задокументовано тут: [Безпека](/uk/gateway/security)
Типові політики DM задокументовано тут: [Безпека](/uk/gateway/security)
`dmPolicy: "open"` є публічною лише тоді, коли ефективний список дозволених DM містить `"*"`.
Налаштування й перевірка потребують цього wildcard для публічних відкритих конфігурацій. Якщо наявний
стан містить `open` із конкретними записами `allowFrom`, середовище виконання все одно допускає
лише цих відправників, а схвалення зі сховища створення пар не розширюють доступ `open`.
Налаштування й перевірка потребують цього wildcard для публічно відкритих конфігурацій. Якщо наявний
стан містить `open` із конкретними записами `allowFrom`, під час виконання все одно допускаються
лише ці відправники, а схвалення в сховищі сполучень не розширюють доступ `open`.
Коди створення пари:
Коди сполучення:
- 8 символів, великі літери, без неоднозначних символів (`0O1I`).
- **Спливають через 1 годину**. Бот надсилає повідомлення про створення пари лише тоді, коли створюється новий запит (приблизно раз на годину для кожного відправника).
- Очікувані запити на створення пари для DM стандартно обмежено **3 на канал**; додаткові запити ігноруються, доки один із них не спливе або не буде схвалений.
- 8 символів, верхній регістр, без неоднозначних символів (`0O1I`).
- **Завершують дію через 1 годину**. Бот надсилає повідомлення про сполучення лише коли створено новий запит (приблизно раз на годину для кожного відправника).
- Очікувані запити на сполучення DM типово обмежено **3 на канал**; додаткові запити ігноруються, доки один із них не завершить дію або не буде схвалений.
### Схвалити відправника
@ -46,18 +46,18 @@ openclaw pairing list telegram
openclaw pairing approve telegram <CODE>
```
Якщо власника команд ще не налаштовано, схвалення коду створення пари для DM також ініціалізує
`commands.ownerAllowFrom` для схваленого відправника, наприклад `telegram:123456789`.
Це дає початковим налаштуванням явного власника для привілейованих команд і запитів
схвалення виконання. Після появи власника подальші схвалення створення пари надають лише
доступ до DM; вони не додають більше власників.
Якщо власника команд ще не налаштовано, схвалення коду сполучення DM також початково налаштовує
`commands.ownerAllowFrom` на схваленого відправника, наприклад `telegram:123456789`.
Це дає початковим налаштуванням явного власника для привілейованих команд і запитів схвалення
exec. Після появи власника подальші схвалення сполучення надають лише доступ 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, так і для груп.
кількох каналів повідомлень або до списків дозволених як DM, так і груп.
Статичні групи використовують `type: "message.senders"` і посилаються через
`accessGroup:<name>` зі списків дозволених каналу:
@ -88,60 +88,67 @@ openclaw pairing approve telegram <CODE>
Зберігається в `~/.openclaw/credentials/`:
- Очікувані запити: `<channel>-pairing.json`
- Схвалене сховище списку дозволених:
- Стандартний обліковий запис: `<channel>-allowFrom.json`
- Нестандартний обліковий запис: `<channel>-<accountId>-allowFrom.json`
- Сховище схваленого списку дозволених:
- Типовий обліковий запис: `<channel>-allowFrom.json`
- Нетиповий обліковий запис: `<channel>-<accountId>-allowFrom.json`
Поведінка області дії облікового запису:
- Нестандартні облікові записи читають/записують лише свій файл списку дозволених з областю дії.
- Стандартний обліковий запис використовує файл списку дозволених каналу без області дії.
- Нетипові облікові записи читають/записують лише свій файл списку дозволених з областю дії.
- Типовий обліковий запис використовує файл списку дозволених каналу без окремої області дії.
Ставтеся до них як до чутливих даних (вони контролюють доступ до вашого асистента).
<Note>
Сховище списку дозволених для створення пар призначене для доступу до DM. Авторизація груп окрема.
Схвалення коду створення пари для DM не дозволяє цьому відправнику автоматично виконувати групові
команди або керувати ботом у групах. Початкова ініціалізація першого власника є окремим станом
конфігурації в `commands.ownerAllowFrom`, а доставлення групових чатів і далі дотримується
групових списків дозволених каналу (наприклад `groupAllowFrom`, `groups` або перевизначень для окремих груп
чи тем залежно від каналу).
Сховище списку дозволених сполучення призначене для доступу DM. Авторизація груп є окремою.
Схвалення коду сполучення DM не дозволяє автоматично цьому відправнику виконувати групові
команди або керувати ботом у групах. Початкове налаштування першого власника є окремим станом
конфігурації в `commands.ownerAllowFrom`, а доставка в групові чати все одно відповідає
груповим спискам дозволених каналу (наприклад `groupAllowFrom`, `groups` або перевизначенням
для окремої групи чи теми залежно від каналу).
</Note>
## 2) Створення пари з Node-пристроєм (iOS/Android/macOS/headless Node)
## 2) Сполучення пристрою Node (iOS/Android/macOS/headless вузли)
Node підключаються до Gateway як **пристрої** з `role: node`. Gateway
створює запит на створення пари з пристроєм, який потрібно схвалити.
Вузли підключаються до Gateway як **пристрої** з `role: node`. Gateway
створює запит на сполучення пристрою, який потрібно схвалити.
### Створення пари через Telegram (рекомендовано для iOS)
### Сполучити через Telegram (рекомендовано для iOS)
Якщо ви використовуєте Plugin `device-pair`, ви можете виконати перше створення пари з пристроєм повністю з Telegram:
Якщо ви використовуєте Plugin `device-pair`, можна виконати перше сполучення пристрою повністю з Telegram:
1. У Telegram надішліть повідомлення своєму боту: `/pair`
2. Бот відповість двома повідомленнями: повідомленням з інструкцією та окремим повідомленням із **кодом налаштування** (його легко копіювати/вставляти в Telegram).
1. У Telegram надішліть своєму боту: `/pair`
2. Бот відповідає двома повідомленнями: повідомленням з інструкціями та окремим повідомленням із **кодом налаштування** (його легко скопіювати/вставити в Telegram).
3. На телефоні відкрийте застосунок OpenClaw для iOS → Settings → Gateway.
4. Вставте код налаштування й підключіться.
4. Відскануйте QR-код або вставте код налаштування й підключіться.
5. Поверніться в Telegram: `/pair pending` (перегляньте ідентифікатори запитів, роль і області дії), потім схваліть.
Код налаштування — це JSON-навантаження, закодоване в base64, яке містить:
Код налаштування — це JSON payload, закодований у base64, який містить:
- `url`: URL WebSocket Gateway (`ws://...` або `wss://...`)
- `bootstrapToken`: короткоживучий bootstrap-токен для одного пристрою, який використовується для початкового рукостискання створення пари
- `bootstrapToken`: короткочасний bootstrap token для одного пристрою, який використовується для початкового рукостискання сполучення
Цей bootstrap-токен має вбудований bootstrap-профіль створення пари:
Цей bootstrap token несе вбудований bootstrap-профіль сполучення:
- основний переданий токен `node` залишається з `scopes: []`
- основний переданий токен `node` залишається `scopes: []`
- будь-який переданий токен `operator` залишається обмеженим bootstrap-списком дозволених:
`operator.approvals`, `operator.read`, `operator.talk.secrets`, `operator.write`
- перевірки bootstrap-областей дії мають префікс ролі, а не один плаский пул областей дії:
записи області дії оператора задовольняють лише запити оператора, а ролі, що не є операторськими,
все одно мають запитувати області дії під власним префіксом ролі
- подальша ротація/відкликання токена залишається обмеженою як схваленим
контрактом ролі пристрою, так і операторськими областями дії сесії викликача
- перевірки bootstrap-областей дії мають префікс ролі, а не один плоский пул областей дії:
записи областей дії operator задовольняють лише запити operator, а ролі не-operator
все одно мають запитувати області дії з власним префіксом ролі
- подальша ротація/відкликання токенів залишається обмеженою як схваленим
контрактом ролі пристрою, так і областями дії operator сесії виклику
Ставтеся до коду налаштування як до пароля, поки він чинний.
Ставтеся до коду налаштування як до пароля, доки він чинний.
### Схвалити Node-пристрій
Для Tailscale, публічного або іншого не-loopback мобільного сполучення використовуйте Tailscale
Serve/Funnel або інший URL Gateway `wss://`. Прямі не-loopback URL налаштування `ws://`
відхиляються до видачі QR/коду налаштування. Відкритотекстові коди налаштування `ws://`
обмежені loopback URL; клієнти приватної мережі `ws://` все одно потребують явного
аварійного перемикача `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1`, описаного в посібнику з віддаленого
Gateway.
### Схвалити пристрій Node
```bash
openclaw devices list
@ -149,25 +156,25 @@ openclaw devices approve <requestId>
openclaw devices reject <requestId>
```
Коли явне схвалення відхилено через те, що сесію схвалювального paired-пристрою
було відкрито лише з областю дії для створення пари, CLI повторює той самий запит із
`operator.admin`. Це дає наявному paired-пристрою з можливостями адміністратора відновити нове
створення пари для Control UI/браузера без ручного редагування `devices/paired.json`.
Gateway усе одно перевіряє повторне підключення; токени, які не можуть автентифікуватися
Коли явне схвалення відхилено, бо сесію схвалювального сполученого пристрою
було відкрито з областю дії лише для сполучення, CLI повторює той самий запит з
`operator.admin`. Це дає наявному сполученому пристрою з можливостями admin змогу відновити нове
сполучення Control UI/браузера без ручного редагування `devices/paired.json`.
Gateway все одно перевіряє повторне підключення; токени, які не можуть автентифікуватися
з `operator.admin`, залишаються заблокованими.
Якщо той самий пристрій повторює спробу з іншими даними автентифікації (наприклад іншими
роллю/областями дії/публічним ключем), попередній очікуваний запит замінюється, і створюється новий
Якщо той самий пристрій повторює спробу з іншими деталями автентифікації (наприклад інша
роль/області дії/публічний ключ), попередній очікуваний запит замінюється і створюється новий
`requestId`.
<Note>
Уже paired-пристрій не отримує ширший доступ непомітно. Якщо він повторно підключається, запитуючи більше областей дії або ширшу роль, OpenClaw зберігає наявне схвалення без змін і створює новий очікуваний запит на підвищення доступу. Використовуйте `openclaw devices list`, щоб порівняти поточний схвалений доступ із новозапитаним доступом перед схваленням.
Уже сполучений пристрій не отримує ширший доступ непомітно. Якщо він повторно підключається, запитуючи більше областей дії або ширшу роль, OpenClaw залишає наявне схвалення без змін і створює новий очікуваний запит на підвищення. Використовуйте `openclaw devices list`, щоб порівняти поточний схвалений доступ із новим запитаним доступом перед схваленням.
</Note>
### Необов’язкове автоматичне схвалення Node з довірених CIDR
### Необов’язкове автоматичне схвалення Node за довіреним CIDR
Створення пари з пристроєм стандартно залишається ручним. Для суворо контрольованих Node-мереж
ви можете ввімкнути автоматичне схвалення першого Node з явними CIDR або точними IP-адресами:
Сполучення пристроїв типово залишається ручним. Для суворо контрольованих мереж Node
можна явно ввімкнути автоматичне схвалення першого підключення Node з явними CIDR або точними IP:
```json5
{
@ -181,29 +188,29 @@ Gateway усе одно перевіряє повторне підключенн
}
```
Це застосовується лише до нових запитів на створення пари `role: node` без запитаних
областей дії. Операторські, браузерні, Control UI та WebChat клієнти все одно потребують ручного
Це застосовується лише до нових запитів сполучення `role: node` без запитаних
областей дії. Клієнти Operator, браузера, Control UI та WebChat усе одно потребують ручного
схвалення. Зміни ролі, області дії, метаданих і публічного ключа все одно потребують ручного
схвалення.
### Зберігання стану створення пари з Node
### Зберігання стану сполучення Node
Зберігається в `~/.openclaw/devices/`:
- `pending.json` (короткоживучий; очікувані запити спливають)
- `paired.json` (paired-пристрої + токени)
- `pending.json` (короткочасний; очікувані запити завершують дію)
- `paired.json` (сполучені пристрої + токени)
### Примітки
- Застарілий API `node.pair.*` (CLI: `openclaw nodes pending|approve|reject|remove|rename`) є
окремим сховищем створення пар, яким володіє gateway. WS Node усе одно потребують створення пари з пристроєм.
- Запис створення пари є довготривалим джерелом істини для схвалених ролей. Активні
токени пристроїв залишаються обмеженими цим схваленим набором ролей; випадковий запис токена
окремим сховищем сполучення, яким володіє Gateway. WS-вузли все одно потребують сполучення пристрою.
- Запис сполучення є довготривалим джерелом істини для схвалених ролей. Активні
токени пристрою залишаються обмеженими цим схваленим набором ролей; випадковий запис токена
поза схваленими ролями не створює нового доступу.
## Пов’язані документи
- Модель безпеки + prompt injection: [Безпека](/uk/gateway/security)
- Модель безпеки + ін’єкція підказок: [Безпека](/uk/gateway/security)
- Безпечне оновлення (запустіть doctor): [Оновлення](/uk/install/updating)
- Конфігурації каналів:
- Telegram: [Telegram](/uk/channels/telegram)