From b4a536b99ae8a84c33ac34ce5a7fbcee15a43f21 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Sat, 25 Apr 2026 20:04:43 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/gateway/pairing.md | 195 ++++++++++++++++++------------------- 1 file changed, 97 insertions(+), 98 deletions(-) diff --git a/docs/uk/gateway/pairing.md b/docs/uk/gateway/pairing.md index 17d2dd213..e9954744c 100644 --- a/docs/uk/gateway/pairing.md +++ b/docs/uk/gateway/pairing.md @@ -1,45 +1,43 @@ --- read_when: - - Реалізація підтверджень зіставлення Node без UI macOS - - Додавання потоків CLI для підтвердження віддалених Node - - Розширення протоколу Gateway для керування Node -summary: Зіставлення Node, яким володіє Gateway (варіант B), для iOS та інших віддалених Node -title: Зіставлення, яким володіє Gateway + - Реалізація підтверджень сполучення вузлів без інтерфейсу macOS + - Додавання потоків CLI для підтвердження віддалених вузлів + - Розширення протоколу Gateway керуванням вузлами +summary: Сполучення вузлів, кероване Gateway (варіант B), для iOS та інших віддалених вузлів +title: Сполучення, кероване Gateway x-i18n: - generated_at: "2026-04-25T05:56:15Z" + generated_at: "2026-04-25T20:04:03Z" model: gpt-5.4 provider: openai - source_hash: 3b512fbf97e7557a1f467732f1b68d8c1b8183695e436b3f87b4c4aca1478cb5 + source_hash: 436391f7576b7285733eb4a8283b73d7b4c52f22b227dd915c09313cfec776bd source_path: gateway/pairing.md workflow: 15 --- -У зіставленні, яким володіє Gateway, **Gateway** є джерелом істини щодо того, яким Node -дозволено приєднуватися. UI (застосунок macOS, майбутні клієнти) — це лише фронтенди, які -підтверджують або відхиляють очікувальні запити. +У сполученні, керованому Gateway, **Gateway** є джерелом істини щодо того, яким вузлам дозволено приєднуватися. Інтерфейси користувача (застосунок macOS, майбутні клієнти) — це лише фронтенди, які підтверджують або відхиляють запити, що очікують на розгляд. -**Важливо:** WS Node використовують **зіставлення пристроїв** (role `node`) під час `connect`. -`node.pair.*` — це окреме сховище зіставлення і воно **не** керує WS handshake. +**Важливо:** вузли WS використовують **сполучення пристрою** (роль `node`) під час `connect`. +`node.pair.*` — це окреме сховище сполучення, і воно **не** контролює WS-handshake. Цей потік використовують лише клієнти, які явно викликають `node.pair.*`. ## Поняття -- **Очікувальний запит**: Node запитав приєднання; потрібне підтвердження. -- **Зіставлений Node**: підтверджений Node із виданим auth-токеном. -- **Транспорт**: WS endpoint Gateway пересилає запити, але не вирішує - членство. (Підтримку застарілого TCP bridge видалено.) +- **Запит, що очікує на розгляд**: вузол попросив приєднатися; потрібне підтвердження. +- **Сполучений вузол**: підтверджений вузол із виданим токеном автентифікації. +- **Транспорт**: кінцева точка Gateway WS пересилає запити, але не вирішує + питання членства. (Підтримку застарілого TCP bridge було видалено.) -## Як працює зіставлення +## Як працює сполучення -1. Node підключається до WS Gateway і запитує зіставлення. -2. Gateway зберігає **очікувальний запит** і генерує `node.pair.requested`. +1. Вузол підключається до Gateway WS і запитує сполучення. +2. Gateway зберігає **запит, що очікує на розгляд**, і генерує `node.pair.requested`. 3. Ви підтверджуєте або відхиляєте запит (CLI або UI). -4. Після підтвердження Gateway видає **новий токен** (токени ротуються під час повторного зіставлення). -5. Node повторно підключається, використовуючи токен, і тепер вважається «зіставленим». +4. Після підтвердження Gateway видає **новий токен** (токени ротуються при повторному сполученні). +5. Вузол перепідключається, використовуючи токен, і тепер є «сполученим». -Очікувальні запити автоматично спливають через **5 хвилин**. +Запити, що очікують на розгляд, автоматично спливають через **5 хвилин**. -## Потік CLI (дружній до headless) +## Робочий процес CLI (зручний для headless) ```bash openclaw nodes pending @@ -49,34 +47,34 @@ openclaw nodes status openclaw nodes rename --node --name "Living Room iPad" ``` -`nodes status` показує зіставлені/підключені Node і їхні можливості. +`nodes status` показує сполучені/підключені вузли та їхні можливості. -## Поверхня API (протокол Gateway) +## Поверхня API (протокол gateway) Події: -- `node.pair.requested` — генерується, коли створюється новий очікувальний запит. -- `node.pair.resolved` — генерується, коли запит підтверджено/відхилено/його строк дії сплив. +- `node.pair.requested` — генерується, коли створено новий запит, що очікує на розгляд. +- `node.pair.resolved` — генерується, коли запит підтверджено/відхилено/прострочено. Методи: -- `node.pair.request` — створити або повторно використати очікувальний запит. -- `node.pair.list` — перелічити очікувальні + зіставлені Node (`operator.pairing`). -- `node.pair.approve` — підтвердити очікувальний запит (видає токен). -- `node.pair.reject` — відхилити очікувальний запит. +- `node.pair.request` — створити або повторно використати запит, що очікує на розгляд. +- `node.pair.list` — показати список вузлів, що очікують на розгляд, і сполучених вузлів (`operator.pairing`). +- `node.pair.approve` — підтвердити запит, що очікує на розгляд (видає токен). +- `node.pair.reject` — відхилити запит, що очікує на розгляд. - `node.pair.verify` — перевірити `{ nodeId, token }`. Примітки: -- `node.pair.request` є ідемпотентним для кожного Node: повторні виклики повертають той самий - очікувальний запит. -- Повторні запити для того самого очікувального Node також оновлюють збережені метадані Node - і найновіший знімок заявлених команд із allowlist для видимості оператора. -- Підтвердження **завжди** генерує новий токен; токен ніколи не повертається з +- `node.pair.request` є ідемпотентним для кожного вузла: повторні виклики повертають той самий + запит, що очікує на розгляд. +- Повторні запити для того самого вузла, що очікує на розгляд, також оновлюють збережені метадані вузла + та останній знімок задекларованих команд із allowlist для видимості оператору. +- Підтвердження **завжди** генерує свіжий токен; токен ніколи не повертається з `node.pair.request`. -- Запити можуть містити `silent: true` як підказку для потоків автоматичного підтвердження. -- `node.pair.approve` використовує заявлені команди очікувального запиту, щоб застосувати - додаткові області підтвердження: +- Запити можуть містити `silent: true` як підказку для потоків автопідтвердження. +- `node.pair.approve` використовує задекларовані команди запиту, що очікує на розгляд, для застосування + додаткових областей підтвердження: - запит без команд: `operator.pairing` - запит команд без exec: `operator.pairing` + `operator.write` - запит `system.run` / `system.run.prepare` / `system.which`: @@ -84,49 +82,49 @@ openclaw nodes rename --node --name "Living Room iPad" Важливо: -- Зіставлення Node — це потік довіри/ідентичності плюс видача токена. -- Воно **не** фіксує поточну поверхню команд Node для кожного Node. -- Поточні команди Node надходять із того, що Node заявляє під час connect після - застосування глобальної політики команд Node gateway (`gateway.nodes.allowCommands` / +- Сполучення вузлів — це потік довіри/ідентичності плюс видача токена. +- Воно **не** закріплює живу поверхню команд вузла для кожного вузла. +- Живі команди вузла надходять із того, що вузол оголошує під час підключення після застосування + глобальної політики команд вузлів gateway (`gateway.nodes.allowCommands` / `denyCommands`). -- Політика allow/ask для `system.run` на рівні окремого Node живе на самому Node в - `exec.approvals.node.*`, а не в записі зіставлення. +- Політика allow/ask для `system.run` на рівні окремого вузла зберігається на вузлі в + `exec.approvals.node.*`, а не в записі сполучення. -## Керування командами Node (2026.3.31+) +## Контроль команд вузла (2026.3.31+) -**Несумісна зміна:** Починаючи з `2026.3.31`, команди Node вимкнені, доки не буде підтверджено зіставлення Node. Самого лише зіставлення пристрою більше недостатньо, щоб відкрити заявлені команди Node. +**Несумісна зміна:** починаючи з `2026.3.31`, команди вузла вимкнено, доки не буде підтверджено сполучення вузла. Самого лише сполучення пристрою більше недостатньо для відкриття задекларованих команд вузла. -Коли Node підключається вперше, запит на зіставлення створюється автоматично. Доки запит на зіставлення не буде підтверджено, усі очікувальні команди Node від цього Node фільтруються і не виконуються. Щойно довіру встановлено через підтвердження зіставлення, заявлені команди Node стають доступними за звичайною політикою команд. +Коли вузол підключається вперше, запит на сполучення створюється автоматично. Доки запит на сполучення не буде підтверджено, усі відкладені команди вузла від цього вузла фільтруються й не виконуються. Щойно довіру встановлено через підтвердження сполучення, задекларовані команди вузла стають доступними відповідно до звичайної політики команд. Це означає: -- Node, які раніше покладалися лише на зіставлення пристрою для відкриття команд, тепер мають завершити зіставлення Node. -- Команди, поставлені в чергу до підтвердження зіставлення, відкидаються, а не відкладаються. +- Вузли, які раніше покладалися лише на сполучення пристрою для відкриття команд, тепер мають завершити сполучення вузла. +- Команди, поставлені в чергу до підтвердження сполучення, відкидаються, а не відкладаються. -## Межі довіри подій Node (2026.3.31+) +## Межі довіри для подій вузла (2026.3.31+) -**Несумісна зміна:** Запуски, ініційовані Node, тепер залишаються на зменшеній довіреній поверхні. +**Несумісна зміна:** запуски, ініційовані вузлом, тепер залишаються в межах звуженої довіреної поверхні. -Зведення, ініційовані Node, і пов’язані події сесії обмежені призначеною довіреною поверхнею. Потоки, керовані сповіщеннями або тригерені Node, які раніше покладалися на ширший доступ до host або session tools, можуть потребувати коригування. Це посилення гарантує, що події Node не можуть підвищити привілеї до доступу до tools рівня host понад межі довіри, дозволені для Node. +Зведення, ініційовані вузлом, і пов’язані події сеансу обмежені призначеною довіреною поверхнею. Потоки, керовані сповіщеннями або ініційовані вузлом, які раніше покладалися на ширший доступ до інструментів хоста або сеансу, можуть потребувати коригування. Це посилення захисту гарантує, що події вузла не зможуть ескалювати до доступу до інструментів рівня хоста понад межі довіри, дозволені для вузла. -## Автоматичне підтвердження (застосунок macOS) +## Автопідтвердження (застосунок macOS) -Застосунок macOS за бажання може спробувати **тихе підтвердження**, коли: +Застосунок macOS може за бажанням спробувати **тихе підтвердження**, якщо: - запит позначено як `silent`, і -- застосунок може перевірити SSH-з’єднання з host Gateway, використовуючи того самого користувача. +- застосунок може перевірити SSH-з’єднання з хостом gateway, використовуючи того самого користувача. -Якщо тихе підтвердження не вдається, відбувається повернення до звичайного запиту «Підтвердити/Відхилити». +Якщо тихе підтвердження не вдається, використовується звичайний запит «Підтвердити/Відхилити». -## Автоматичне підтвердження пристроїв для довірених CIDR +## Автопідтвердження пристроїв із Trusted-CIDR -WS-зіставлення пристроїв для `role: node`, як і раніше, типово виконується вручну. Для приватних -мереж Node, де Gateway уже довіряє мережевому шляху, оператори можуть -увімкнути це явно через CIDR або точні IP: +WS-сполучення пристроїв для `role: node` типово лишається ручним. Для приватних +мереж вузлів, де Gateway вже довіряє мережевому шляху, оператори можуть +увімкнути це явно за допомогою CIDR або точних IP-адрес: ```json5 { @@ -142,66 +140,67 @@ WS-зіставлення пристроїв для `role: node`, як і ран Межа безпеки: -- Вимкнено, коли `gateway.nodes.pairing.autoApproveCidrs` не задано. -- Не існує загального режиму автоматичного підтвердження для LAN або приватної мережі. -- Право мають лише нові зіставлення пристроїв `role: node` без запитаних scopes. -- Клієнти Operator, browser, Control UI і WebChat залишаються ручними. -- Оновлення role, scope, metadata і public key залишаються ручними. -- Шляхи заголовків trusted proxy через loopback на тому самому host не мають права на це, бо цей - шлях може бути підроблений локальними викликачами. +- Вимкнено, якщо `gateway.nodes.pairing.autoApproveCidrs` не задано. +- Режиму загального автопідтвердження для LAN або приватної мережі не існує. +- Підходить лише свіже сполучення пристрою `role: node` без запитаних областей. +- Клієнти Operator, browser, Control UI і WebChat лишаються ручними. +- Оновлення ролі, області, метаданих і публічного ключа лишаються ручними. +- Шляхи trusted-proxy header loopback того самого хоста не підходять, оскільки + цей шлях може бути підроблений локальними викликачами. -## Автоматичне підтвердження оновлення metadata +## Автопідтвердження оновлення метаданих -Коли вже зіставлений пристрій підключається знову лише зі змінами нечутливих -metadata (наприклад, display name або підказок платформи клієнта), OpenClaw розглядає -це як `metadata-upgrade`. Тихе автоматичне підтвердження є вузьким: воно застосовується лише до -довірених локальних CLI/helper повторних підключень, які вже довели володіння -спільним токеном або паролем через loopback. Клієнти browser/Control UI і віддалені -клієнти, як і раніше, використовують явний потік повторного підтвердження. Оновлення scope (з read до -write/admin) і зміни public key **не** мають права на автоматичне підтвердження `metadata-upgrade` — +Коли вже сполучений пристрій перепідключається лише з несуттєвими змінами +метаданих (наприклад, відображуваної назви або підказок щодо клієнтської платформи), OpenClaw трактує +це як `metadata-upgrade`. Тихе автопідтвердження є вузьким: воно застосовується лише +до довірених небраузерних локальних перепідключень, які вже довели володіння локальними +або спільними обліковими даними, зокрема до повторних підключень рідних застосунків на тому самому хості після змін +метаданих версії ОС. Клієнти browser/Control UI та віддалені клієнти, як і раніше, +використовують явний потік повторного підтвердження. Підвищення області (з read до write/admin) і зміни +публічного ключа **не** підходять для автопідтвердження `metadata-upgrade` — вони залишаються явними запитами на повторне підтвердження. -## Допоміжні засоби QR-зіставлення +## Допоміжні засоби QR-сполучення -`/pair qr` відтворює payload зіставлення як структуровані медіадані, щоб мобільні й -browser-клієнти могли сканувати його безпосередньо. +`/pair qr` відтворює payload сполучення як структуроване медіа, щоб мобільні та +браузерні клієнти могли сканувати його безпосередньо. -Видалення пристрою також очищає всі застарілі очікувальні запити на зіставлення для цього -id пристрою, тож `nodes pending` не показує осиротілі рядки після відкликання. +Видалення пристрою також очищає будь-які застарілі запити на сполучення, що очікують на розгляд, для цього +ідентифікатора пристрою, тож `nodes pending` не показує осиротілі рядки після відкликання. ## Локальність і переслані заголовки -Під час зіставлення Gateway вважає з’єднання loopback лише тоді, коли і raw socket, -і будь-які свідчення проксі вище за ланцюжком збігаються. Якщо запит надходить через loopback, але -містить заголовки `X-Forwarded-For` / `X-Forwarded-Host` / `X-Forwarded-Proto`, які вказують -на нелокальне джерело, ці свідчення пересланих заголовків скасовують твердження про локальність loopback. -Тоді шлях зіставлення вимагає явного підтвердження замість -тихого трактування запиту як підключення з того самого host. Див. -[Автентифікація Trusted Proxy](/uk/gateway/trusted-proxy-auth) для еквівалентного правила щодо -auth оператора. +Під час сполучення Gateway вважає з’єднання loopback лише тоді, коли і сирий сокет, +і будь-які свідчення від проксі вище за потоком узгоджуються. Якщо запит надходить через loopback, але +містить заголовки `X-Forwarded-For` / `X-Forwarded-Host` / `X-Forwarded-Proto`, +які вказують на нелокальне джерело, ці свідчення пересланих заголовків скасовують +твердження про loopback-локальність. Тоді шлях сполучення вимагає явного підтвердження +замість того, щоб тихо трактувати запит як підключення з того самого хоста. Див. +[Trusted Proxy Auth](/uk/gateway/trusted-proxy-auth) для еквівалентного правила в +автентифікації оператора. ## Зберігання (локальне, приватне) -Стан зіставлення зберігається в каталозі стану Gateway (типово `~/.openclaw`): +Стан сполучення зберігається в каталозі стану Gateway (типово `~/.openclaw`): - `~/.openclaw/nodes/paired.json` - `~/.openclaw/nodes/pending.json` -Якщо ви перевизначаєте `OPENCLAW_STATE_DIR`, теку `nodes/` буде перенесено разом із ним. +Якщо ви перевизначите `OPENCLAW_STATE_DIR`, папка `nodes/` переміститься разом із ним. Примітки щодо безпеки: -- Токени — це секрети; ставтеся до `paired.json` як до чутливого файлу. -- Ротація токена вимагає повторного підтвердження (або видалення запису Node). +- Токени є секретами; ставтеся до `paired.json` як до чутливого файлу. +- Ротація токена вимагає повторного підтвердження (або видалення запису вузла). ## Поведінка транспорту -- Транспорт є **безстановим**; він не зберігає членство. -- Якщо Gateway офлайн або зіставлення вимкнено, Node не можуть зіставлятися. -- Якщо Gateway працює у віддаленому режимі, зіставлення все одно відбувається зі сховищем віддаленого Gateway. +- Транспорт є **безстановим**; він не зберігає відомості про членство. +- Якщо Gateway недоступний або сполучення вимкнено, вузли не можуть виконати сполучення. +- Якщо Gateway працює у віддаленому режимі, сполучення все одно відбувається зі сховищем віддаленого Gateway. ## Пов’язане -- [Зіставлення каналів](/uk/channels/pairing) -- [Node](/uk/nodes) +- [Сполучення каналів](/uk/channels/pairing) +- [Вузли](/uk/nodes) - [CLI пристроїв](/uk/cli/devices)