- Parowanie wiadomości prywatnych (kto może komunikować się z botem)
- Parowanie Node (które urządzenia/węzły mogą dołączać do sieci Gateway)
1) Parowanie wiadomości prywatnych (dostęp do czatu przychodzącego)
Gdy kanał jest skonfigurowany z zasadą wiadomości prywatnychpairing, nieznani nadawcy otrzymują krótki kod, a ich wiadomość nie jest przetwarzana do czasu zatwierdzenia.
Domyślne zasady wiadomości prywatnych opisano w: Bezpieczeństwo
dmPolicy: "open" jest publiczne tylko wtedy, gdy efektywna lista dozwolonych nadawców wiadomości prywatnych zawiera "*".
Konfiguracja i walidacja wymagają tego symbolu wieloznacznego w konfiguracjach otwartych publicznie. Jeśli istniejący
stan zawiera open z konkretnymi wpisami allowFrom, środowisko uruchomieniowe nadal dopuszcza
tylko tych nadawców, a zatwierdzenia w magazynie parowania nie rozszerzają dostępu open.
Kody parowania:
- 8 znaków, wielkie litery, bez niejednoznacznych znaków (
0O1I). - Wygasają po 1 godzinie. Bot wysyła wiadomość dotyczącą parowania tylko po utworzeniu nowego żądania (w przybliżeniu raz na godzinę dla każdego nadawcy).
- Liczba oczekujących żądań parowania wiadomości prywatnych jest ograniczona do 3 na konto kanału; dodatkowe żądania są ignorowane do czasu wygaśnięcia lub zatwierdzenia jednego z nich.
Zatwierdzanie nadawcy
--notify do polecenia zatwierdzającego, aby powiadomić osobę wysyłającą żądanie w tym samym kanale. Kanały obsługujące wiele kont przyjmują --account <id>.
Jeśli nie skonfigurowano jeszcze właściciela poleceń, zatwierdzenie kodu parowania wiadomości prywatnej inicjuje również
commands.ownerAllowFrom dla zatwierdzonego nadawcy, na przykład telegram:123456789.
Zapewnia to nowym konfiguracjom jawnego właściciela poleceń uprzywilejowanych i monitów
o zatwierdzenie wykonywania poleceń. Gdy właściciel już istnieje, późniejsze zatwierdzenia parowania przyznają tylko dostęp
do wiadomości prywatnych; nie dodają kolejnych właścicieli.
Obsługiwane kanały (każdy zainstalowany Plugin kanału deklarujący parowanie; zewnętrzne Pluginy, takie jak openclaw-weixin, mogą dodawać kolejne): discord, feishu, googlechat, imessage, irc, line, matrix, mattermost, msteams, nextcloud-talk, nostr, signal, slack, sms, synology-chat, telegram, twitch, whatsapp, zalo, zalouser.
Grupy nadawców wielokrotnego użytku
UżyjaccessGroups najwyższego poziomu, gdy ten sam zestaw zaufanych nadawców ma być stosowany do
wielu kanałów wiadomości lub zarówno do list dozwolonych nadawców wiadomości prywatnych, jak i grupowych.
Grupy statyczne używają type: "message.senders" i są przywoływane przez
accessGroup:<name> na listach dozwolonych nadawców kanałów:
Lokalizacja stanu
Stan jest przechowywany we współdzielonej bazie danych stanu SQLite pod adresem~/.openclaw/state/openclaw.sqlite:
- oczekujące żądania w
channel_pairing_requests - zatwierdzeni nadawcy w
channel_pairing_allow_entries
- każde żądanie i każdy zatwierdzony nadawca są identyfikowani według kanału i konta
- środowisko uruchomieniowe odczytuje tylko kanoniczne wiersze SQLite; nie scala starszych plików
<channel>-pairing.json i
<channel>-<accountId>-allowFrom.json w ~/.openclaw/credentials/.
Migracja podczas uruchamiania i openclaw doctor --fix importują te pliki do SQLite i
usuwają każde źródło po pomyślnym imporcie. Bazę danych SQLite należy traktować jako
poufną, ponieważ te wiersze kontrolują dostęp do asystenta.
Magazyn listy dozwolonych nadawców parowania służy do obsługi dostępu do wiadomości prywatnych. Autoryzacja grupowa jest oddzielna.
Zatwierdzenie kodu parowania wiadomości prywatnej nie zezwala automatycznie temu nadawcy na wykonywanie poleceń
grupowych ani sterowanie botem w grupach. Inicjalizacja pierwszego właściciela stanowi oddzielny stan konfiguracji
w
commands.ownerAllowFrom, a dostarczanie wiadomości na czacie grupowym nadal podlega
listom dozwolonych nadawców grupowych kanału (na przykład groupAllowFrom, groups albo nadpisaniom dla poszczególnych grup
lub tematów, zależnie od kanału).2) Parowanie urządzeń Node (węzły iOS/Android/macOS/bez interfejsu)
Węzły łączą się z Gateway jako urządzenia zrole: node. Gateway
tworzy żądanie parowania urządzenia, które musi zostać zatwierdzone.
Parowanie z poziomu Control UI (zalecane)
Użyj już połączonej sesji Control UI z dostępemoperator.admin:
- Otwórz Control UI i przejdź do Settings → Devices.
- Na stronie Devices kliknij Pair mobile device.
- Pozostaw wybraną opcję Full access (recommended) lub wybierz Limited access, aby pominąć administracyjne elementy sterujące Gateway.
- Kliknij Create setup code.
- Na telefonie otwórz aplikację OpenClaw → Settings → Gateway.
- Zeskanuj kod QR lub wklej kod konfiguracji, a następnie nawiąż połączenie.
Parowanie przez Telegram
Jeśli używany jest Plugindevice-pair, pierwsze parowanie urządzenia można przeprowadzić w całości w Telegram:
- W Telegram wyślij do bota wiadomość:
/pair - Bot odpowie dwiema wiadomościami: wiadomością z instrukcjami i oddzielną wiadomością zawierającą kod konfiguracji (łatwy do skopiowania i wklejenia w Telegram).
- Na telefonie otwórz aplikację OpenClaw na iOS → Settings → Gateway.
- Zeskanuj kod QR (
/pair qr) lub wklej kod konfiguracji i nawiąż połączenie. - Oficjalna aplikacja mobilna połączy się automatycznie. Jeśli
/pair pendingwyświetli żądanie, przed jego zatwierdzeniem należy sprawdzić rolę i zakresy.
url: adres URL WebSocket Gateway (ws://...lubwss://...)urls: jeśli są dostępne, uporządkowane trasy LAN/Tailnet, które aplikacja mobilna może wypróbowaćbootstrapToken: jednorazowy token inicjujący pierwszą procedurę uzgadniania parowania; Gateway unieważnia go po 10 minutach
/pair cleanup, aby unieważnić niewykorzystane kody konfiguracji.
Ten token inicjujący zawiera wbudowany profil inicjowania parowania:
- bezpieczna konfiguracja
wss://(lub sprzężenie zwrotne tego samego hosta) domyślnie zapewnianodeoraz pełny natywny mobilny dostępoperator - przekazany token
nodepozostajescopes: [] - domyślny przekazany token
operatorobejmujeoperator.admin,operator.approvals,operator.read,operator.talk.secretsorazoperator.write - Opcja Control UI Limited access oraz
openclaw qr --limitedpomijająoperator.admin, zachowując pozostałe zakresy operatora - konfiguracja zwykłego tekstu
ws://w sieci LAN automatycznie używa tego samego ograniczonego profilu; skonfigurujwss://lub Tailscale Serve i wygeneruj nowy kod, aby uzyskać pełny dostęp - późniejsze obracanie lub unieważnianie tokenów pozostaje ograniczone zarówno przez zatwierdzoną umowę roli urządzenia, jak i zakresy operatora sesji wywołującej
wss:// lub
Tailscale Serve, następnie wygenerować nowy kod konfiguracji z pełnym dostępem, zeskanować go lub wkleić
na tej stronie ustawień i ponownie nawiązać połączenie.
Do zdalnego parowania urządzeń mobilnych za pośrednictwem Tailscale, sieci publicznej lub innych metod należy użyć Tailscale Serve/Funnel
albo innego adresu URL Gateway wss://. Kody konfiguracji ze zwykłym tekstem ws:// są akceptowane tylko
dla adresów sprzężenia zwrotnego, prywatnych adresów LAN, hostów Bonjour .local i hosta
emulatora Androida. Trasy ze zwykłym tekstem niebędące sprzężeniem zwrotnym otrzymują ograniczony dostęp. Adresy CGNAT
Tailnet, nazwy .ts.net i hosty publiczne nadal są domyślnie odrzucane przed
wydaniem kodu QR/kodu konfiguracji.
W przypadku adresów URL konfiguracji gateway.bind=lan OpenClaw wykrywa trwałe główne adresy HTTPS Tailscale Serve,
które pośredniczą do portu sprzężenia zwrotnego aktywnego Gateway, i ogłasza je
wraz z trasą LAN. Polecenie konfiguracji dodaje tę trasę awaryjną tylko
dla lan; custom i tailnet zachowują jawnie ogłaszane trasy. Aplikacja
na iOS sprawdza ogłaszane trasy w kolejności i zapisuje pierwszy osiągalny
punkt końcowy.
Zatwierdzanie urządzenia Node
operator.admin. Pozwala to istniejącemu sparowanemu urządzeniu z uprawnieniami administratora odzyskać nowe
parowanie Control UI/przeglądarki bez ręcznego edytowania magazynu parowania. Gateway
nadal weryfikuje ponowione połączenie; tokeny, które nie mogą zostać uwierzytelnione
za pomocą operator.admin, pozostają zablokowane.
Jeśli to samo urządzenie ponowi próbę z innymi danymi uwierzytelniającymi (na przykład inną
rolą, innymi zakresami lub kluczem publicznym), poprzednie oczekujące żądanie zostanie zastąpione i zostanie utworzony nowy
requestId.
Już sparowane urządzenie nie uzyskuje po cichu szerszego dostępu. Jeśli ponownie łączy się, żądając większej liczby zakresów lub szerszej roli, OpenClaw pozostawia istniejące zatwierdzenie bez zmian i tworzy nowe oczekujące żądanie rozszerzenia. Przed zatwierdzeniem użyj
openclaw devices list, aby porównać obecnie zatwierdzony dostęp z nowo żądanym dostępem.Opcjonalne automatyczne zatwierdzanie Node z zaufanych zakresów CIDR
Parowanie urządzeń domyślnie pozostaje ręczne. W ściśle kontrolowanych sieciach węzłów można włączyć automatyczne zatwierdzanie pierwszego parowania Node za pomocą jawnych zakresów CIDR lub dokładnych adresów IP:role: node, które nie mają żądanych
zakresów. Klienci operatora, przeglądarki, Control UI i WebChat nadal wymagają ręcznego
zatwierdzenia. Zmiany roli, zakresu, metadanych i klucza publicznego nadal wymagają ręcznego
zatwierdzenia.
Przechowywanie stanu parowania Node
Stan jest przechowywany we współdzielonej bazie danych stanu SQLite pod adresem~/.openclaw/state/openclaw.sqlite:
- oczekujące żądania parowania urządzeń (krótkotrwałe; wygasają po 5 minutach)
- sparowane urządzenia i tokeny
~/.openclaw/devices/*.json; pliki te są
importowane do SQLite podczas uruchamiania Gateway i archiwizowane z przyrostkiem .migrated.
Uwagi
- Interfejs API
node.pair.*(CLI:openclaw nodes pending|approve|reject|remove|rename) zarządza zatwierdzeniami możliwości Node przechowywanymi w tych samych rekordach sparowanych urządzeń. Węzły WS nadal wymagają parowania urządzenia; zobacz Parowanie Node. - Rekord parowania jest trwałym źródłem prawdy o zatwierdzonych rolach. Aktywne tokeny urządzeń pozostają ograniczone do tego zatwierdzonego zestawu ról; przypadkowy wpis tokenu spoza zatwierdzonych ról nie tworzy nowego dostępu.
Powiązana dokumentacja
- Model bezpieczeństwa i wstrzykiwanie promptów: Bezpieczeństwo
- Bezpieczne aktualizowanie (uruchom doctor): Aktualizowanie
- Konfiguracje kanałów: