Protokół Gateway

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.

​

Transport

• WebSocket, ramki tekstowe z ładunkami JSON.
• Pierwsza ramka musi być żądaniem connect.
• Ramki przed połączeniem są ograniczone do 64 KiB. Po udanym uzgodnieniu połączenia klienci powinni przestrzegać limitów hello-ok.policy.maxPayload oraz hello-ok.policy.maxBufferedBytes. Gdy diagnostyka jest włączona, zbyt duże ramki przychodzące i powolne bufory wychodzące emitują zdarzenia payload.large zanim Gateway zamknie lub odrzuci daną ramkę. Te zdarzenia zachowują rozmiary, limity, powierzchnie i bezpieczne kody powodów. Nie zachowują treści wiadomości, zawartości załączników, surowej treści ramki, tokenów, ciasteczek ani wartości tajnych.

​

Uzgadnianie połączenia (connect)

{
  "type": "event",
  "event": "connect.challenge",
  "payload": { "nonce": "…", "ts": 1737264000000 }
}

{
  "type": "req",
  "id": "…",
  "method": "connect",
  "params": {
    "minProtocol": 3,
    "maxProtocol": 4,
    "client": {
      "id": "cli",
      "version": "1.2.3",
      "platform": "macos",
      "mode": "operator"
    },
    "role": "operator",
    "scopes": ["operator.read", "operator.write"],
    "caps": [],
    "commands": [],
    "permissions": {},
    "auth": { "token": "…" },
    "locale": "en-US",
    "userAgent": "openclaw-cli/1.2.3",
    "device": {
      "id": "device_fingerprint",
      "publicKey": "…",
      "signature": "…",
      "signedAt": 1737264000000,
      "nonce": "…"
    }
  }
}

{
  "type": "res",
  "id": "…",
  "ok": true,
  "payload": {
    "type": "hello-ok",
    "protocol": 4,
    "server": { "version": "…", "connId": "…" },
    "features": { "methods": ["…"], "events": ["…"] },
    "snapshot": { "…": "…" },
    "auth": {
      "role": "operator",
      "scopes": ["operator.read", "operator.write"]
    },
    "policy": {
      "maxPayload": 26214400,
      "maxBufferedBytes": 52428800,
      "tickIntervalMs": 15000
    }
  }
}

{
  "auth": {
    "role": "operator",
    "scopes": ["operator.read", "operator.write"]
  }
}

{
  "auth": {
    "deviceToken": "…",
    "role": "operator",
    "scopes": ["operator.read", "operator.write"]
  }
}

{
  "auth": {
    "deviceToken": "…",
    "role": "node",
    "scopes": [],
    "deviceTokens": [
      {
        "deviceToken": "…",
        "role": "operator",
        "scopes": ["operator.approvals", "operator.read", "operator.talk.secrets", "operator.write"]
      }
    ]
  }
}

​

Przykład Node

{
  "type": "req",
  "id": "…",
  "method": "connect",
  "params": {
    "minProtocol": 3,
    "maxProtocol": 4,
    "client": {
      "id": "ios-node",
      "version": "1.2.3",
      "platform": "ios",
      "mode": "node"
    },
    "role": "node",
    "scopes": [],
    "caps": ["camera", "canvas", "screen", "location", "voice"],
    "commands": ["camera.snap", "canvas.navigate", "screen.record", "location.get"],
    "permissions": { "camera.capture": true, "screen.record": false },
    "auth": { "token": "…" },
    "locale": "en-US",
    "userAgent": "openclaw-ios/1.2.3",
    "device": {
      "id": "device_fingerprint",
      "publicKey": "…",
      "signature": "…",
      "signedAt": 1737264000000,
      "nonce": "…"
    }
  }
}

​

Ramkowanie

• Żądanie: {type:"req", id, method, params}
• Odpowiedź: {type:"res", id, ok, payload|error}
• Zdarzenie: {type:"event", event, payload, seq?, stateVersion?}

​

Role + zakresy

​

Role

• operator = klient płaszczyzny sterowania (CLI/UI/automatyzacja).
• node = host możliwości (camera/screen/canvas/system.run).

​

Zakresy (operator)

• operator.read
• operator.write
• operator.admin
• operator.approvals
• operator.pairing
• operator.talk.secrets

• żądania bez poleceń: operator.pairing
• żądania z poleceniami węzła innymi niż exec: operator.pairing + operator.write
• żądania obejmujące system.run, system.run.prepare lub system.which: operator.pairing + operator.admin

​

Możliwości/polecenia/uprawnienia (węzeł)

• caps: wysokopoziomowe kategorie możliwości, takie jak camera, canvas, screen, location, voice i talk.
• commands: lista dozwolonych poleceń dla invoke.
• permissions: szczegółowe przełączniki (np. screen.record, camera.capture).

​

Obecność

• system-presence zwraca wpisy indeksowane tożsamością urządzenia.
• Wpisy obecności obejmują deviceId, roles i scopes, aby UI mogły pokazać jeden wiersz na urządzenie nawet wtedy, gdy łączy się ono zarówno jako operator, jak i node.
• node.list zawiera opcjonalne pola lastSeenAtMs i lastSeenReason. Połączone węzły raportują swój bieżący czas połączenia jako lastSeenAtMs z powodem connect; sparowane węzły mogą także raportować trwałą obecność w tle, gdy zaufane zdarzenie węzła aktualizuje ich metadane parowania.

​

Zdarzenie działania węzła w tle

{
  "event": "node.presence.alive",
  "payloadJSON": "{\"trigger\":\"silent_push\",\"sentAtMs\":1737264000000,\"displayName\":\"Peter's iPhone\",\"version\":\"2026.4.28\",\"platform\":\"iOS 18.4.0\",\"deviceFamily\":\"iPhone\",\"modelIdentifier\":\"iPhone17,1\",\"pushTransport\":\"relay\"}"
}

{
  "ok": true,
  "event": "node.presence.alive",
  "handled": true,
  "reason": "persisted"
}

​

Zakresowanie zdarzeń broadcast

• Ramki czatu, agenta i wyników narzędzi (w tym strumieniowane zdarzenia agent i wyniki wywołań narzędzi) wymagają co najmniej operator.read. Sesje bez operator.read całkowicie pomijają te ramki.
• Broadcasty plugin.* zdefiniowane przez pluginy są bramkowane do operator.write lub operator.admin, zależnie od sposobu ich zarejestrowania przez plugin.
• Zdarzenia statusu i transportu (heartbeat, presence, tick, cykl życia connect/disconnect itd.) pozostają nieograniczone, aby kondycja transportu była obserwowalna dla każdej uwierzytelnionej sesji.
• Nieznane rodziny zdarzeń broadcast są domyślnie bramkowane zakresem (fail-closed), chyba że zarejestrowany handler jawnie je rozluźnia.

​

Typowe rodziny metod RPC

​

Typowe rodziny zdarzeń

• chat: aktualizacje czatu UI, takie jak chat.inject, oraz inne zdarzenia czatu dotyczące wyłącznie transkrypcji.
• session.message i session.tool: aktualizacje transkrypcji/strumienia zdarzeń dla subskrybowanej sesji.
• sessions.changed: zmieniono indeks sesji lub metadane.
• presence: aktualizacje migawki obecności systemu.
• tick: okresowe zdarzenie keepalive / żywotności.
• health: aktualizacja migawki kondycji gateway.
• heartbeat: aktualizacja strumienia zdarzeń Heartbeat.
• cron: zdarzenie zmiany uruchomienia/zadania Cron.
• shutdown: powiadomienie o zamknięciu gateway.
• node.pair.requested / node.pair.resolved: cykl życia parowania węzła.
• node.invoke.request: emisja żądania wywołania węzła.
• device.pair.requested / device.pair.resolved: cykl życia sparowanego urządzenia.
• voicewake.changed: zmieniono konfigurację wyzwalacza słowa wybudzającego.
• exec.approval.requested / exec.approval.resolved: cykl życia zatwierdzenia wykonania.
• plugin.approval.requested / plugin.approval.resolved: cykl życia zatwierdzenia Plugin.

​

Metody pomocnicze węzła

• Węzły mogą wywoływać skills.bins, aby pobrać bieżącą listę plików wykonywalnych skill na potrzeby kontroli automatycznego zezwalania.

​

RPC rejestru zadań

• tasks.list wymaga operator.read.
  • Parametry: opcjonalny status ("queued", "running", "completed", "failed", "cancelled" lub "timed_out") albo tablica tych statusów, opcjonalny agentId, opcjonalny sessionKey, opcjonalny limit od 1 do 500 oraz opcjonalny ciąg cursor.
  • Wynik: { "tasks": TaskSummary[], "nextCursor"?: string }.
• tasks.get wymaga operator.read.
  • Parametry: { "taskId": string }.
  • Wynik: { "task": TaskSummary }.
  • Brakujące identyfikatory zadań zwracają kształt błędu Gateway typu not-found.
• tasks.cancel wymaga operator.write.
  • Parametry: { "taskId": string, "reason"?: string }.
  • Wynik: { "found": boolean, "cancelled": boolean, "reason"?: string, "task"?: TaskSummary }.
  • found informuje, czy rejestr zawierał pasujące zadanie. cancelled informuje, czy runtime zaakceptował albo zarejestrował anulowanie.

​

Metody pomocnicze operatora

• Operatorzy mogą wywołać commands.list (operator.read), aby pobrać inwentarz poleceń runtime dla agenta.
  • agentId jest opcjonalne; pomiń je, aby odczytać domyślny obszar roboczy agenta.
  • scope kontroluje, do której powierzchni odnosi się podstawowa wartość name:
    • text zwraca podstawowy token polecenia tekstowego bez początkowego /
    • native i domyślna ścieżka both zwracają natywne nazwy świadome providera, gdy są dostępne
  • textAliases przenosi dokładne aliasy ukośnikowe, takie jak /model i /m.
  • nativeName przenosi natywną nazwę polecenia świadomą providera, gdy taka istnieje.
  • provider jest opcjonalne i wpływa tylko na nazewnictwo natywne oraz dostępność natywnych poleceń plugin.
  • includeArgs=false pomija zserializowane metadane argumentów w odpowiedzi.
• Operatorzy mogą wywołać tools.catalog (operator.read), aby pobrać katalog narzędzi runtime dla agenta. Odpowiedź zawiera pogrupowane narzędzia oraz metadane pochodzenia:
  • source: core lub plugin
  • pluginId: właściciel plugin, gdy source="plugin"
  • optional: czy narzędzie plugin jest opcjonalne
• Operatorzy mogą wywołać tools.effective (operator.read), aby pobrać efektywny w runtime inwentarz narzędzi dla sesji.
  • sessionKey jest wymagane.
  • Gateway wyprowadza zaufany kontekst runtime z sesji po stronie serwera, zamiast akceptować kontekst uwierzytelniania lub dostarczania podany przez wywołującego.
  • Odpowiedź jest ograniczona do sesji i odzwierciedla to, czego aktywna rozmowa może użyć teraz, w tym narzędzia core, plugin i kanału.
• Operatorzy mogą wywołać tools.invoke (operator.write), aby wywołać jedno dostępne narzędzie przez tę samą ścieżkę polityki gateway co /tools/invoke.
  • name jest wymagane. args, sessionKey, agentId, confirm i idempotencyKey są opcjonalne.
  • Jeśli obecne są jednocześnie sessionKey i agentId, rozwiązany agent sesji musi pasować do agentId.
  • Odpowiedź jest kopertą przeznaczoną dla SDK z polami ok, toolName, opcjonalnym output oraz typowanymi polami error. Odmowy wynikające z zatwierdzeń lub polityki zwracają ok:false w ładunku, zamiast omijać potok polityki narzędzi gateway.
• Operatorzy mogą wywołać skills.status (operator.read), aby pobrać widoczny inwentarz skill dla agenta.
  • agentId jest opcjonalne; pomiń je, aby odczytać domyślny obszar roboczy agenta.
  • Odpowiedź zawiera kwalifikowalność, brakujące wymagania, kontrole konfiguracji oraz oczyszczone opcje instalacji bez ujawniania surowych wartości sekretów.
• Operatorzy mogą wywołać skills.search i skills.detail (operator.read) dla metadanych odkrywania ClawHub.
• Operatorzy mogą wywołać skills.upload.begin, skills.upload.chunk i skills.upload.commit (operator.admin), aby przygotować prywatne archiwum skill przed jego instalacją. Jest to osobna ścieżka przesyłania administracyjnego dla zaufanych klientów, a nie zwykły przepływ instalowania skill z ClawHub, i jest domyślnie wyłączona, chyba że włączono skills.install.allowUploadedArchives.
  • skills.upload.begin({ kind: "skill-archive", slug, sizeBytes, sha256?, force?, idempotencyKey? }) tworzy przesyłanie powiązane z tym slug i wartością force.
  • skills.upload.chunk({ uploadId, offset, dataBase64 }) dopisuje bajty pod dokładnym zdekodowanym przesunięciem.
  • skills.upload.commit({ uploadId, sha256? }) weryfikuje końcowy rozmiar i SHA-256. Commit tylko finalizuje przesłanie; nie instaluje skill.
  • Przesłane archiwa skill to archiwa zip zawierające główny SKILL.md. Wewnętrzna nazwa katalogu archiwum nigdy nie wybiera celu instalacji.
• Operatorzy mogą wywołać skills.install (operator.admin) w trzech trybach:
  • Tryb ClawHub: { source: "clawhub", slug, version?, force? } instaluje folder skill w katalogu skills/ domyślnego obszaru roboczego agenta.
  • Tryb przesyłania: { source: "upload", uploadId, slug, force?, sha256?, timeoutMs? } instaluje zatwierdzone przesłanie w katalogu skills/<slug> domyślnego obszaru roboczego agenta. Slug i wartość force muszą pasować do pierwotnego żądania skills.upload.begin. Ten tryb jest odrzucany, chyba że włączono skills.install.allowUploadedArchives. To ustawienie nie wpływa na instalacje ClawHub.
  • Tryb instalatora Gateway: { name, installId, dangerouslyForceUnsafeInstall?, timeoutMs? } uruchamia zadeklarowaną akcję metadata.openclaw.install na hoście gateway.
• Operatorzy mogą wywołać skills.update (operator.admin) w dwóch trybach:
  • Tryb ClawHub aktualizuje jeden śledzony slug lub wszystkie śledzone instalacje ClawHub w domyślnym obszarze roboczym agenta.
  • Tryb konfiguracji aktualizuje wartości skills.entries.<skillKey>, takie jak enabled, apiKey i env.

​

Widoki models.list

• Pominięty lub "default": bieżące zachowanie runtime. Jeśli skonfigurowano agents.defaults.models, odpowiedzią jest dozwolony katalog, w tym dynamicznie odkryte modele dla wpisów provider/*. W przeciwnym razie odpowiedzią jest pełny katalog Gateway.
• "configured": zachowanie o rozmiarze selektora. Jeśli skonfigurowano agents.defaults.models, nadal ma pierwszeństwo, w tym odkrywanie ograniczone do providera dla wpisów provider/*. Bez listy dozwolonych odpowiedź używa jawnych wpisów models.providers.*.models, wracając do pełnego katalogu tylko wtedy, gdy nie istnieją żadne skonfigurowane wiersze modeli.
• "all": pełny katalog Gateway, z pominięciem agents.defaults.models. Używaj tego do diagnostyki i interfejsów odkrywania, a nie w zwykłych selektorach modeli.

​

Zatwierdzenia wykonań

• Gdy żądanie wykonania wymaga zatwierdzenia, gateway emituje exec.approval.requested.
• Klienci operatora rozstrzygają je, wywołując exec.approval.resolve (wymaga zakresu operator.approvals).
• Dla host=node żądanie exec.approval.request musi zawierać systemRunPlan (kanoniczne argv/cwd/rawCommand/metadane sesji). Żądania bez systemRunPlan są odrzucane.
• Po zatwierdzeniu przekazane wywołania node.invoke system.run ponownie używają tego kanonicznego systemRunPlan jako autorytatywnego kontekstu polecenia/cwd/sesji.
• Jeśli wywołujący zmieni command, rawCommand, cwd, agentId lub sessionKey między przygotowaniem a ostatecznym zatwierdzonym przekazaniem system.run, gateway odrzuca uruchomienie zamiast ufać zmodyfikowanemu ładunkowi.

​

Awaryjna ścieżka dostarczania agenta

• Żądania agent mogą zawierać deliver=true, aby zażądać dostarczenia wychodzącego.
• bestEffortDeliver=false zachowuje ścisłe działanie: nierozwiązane lub wyłącznie wewnętrzne cele dostarczania zwracają INVALID_REQUEST.
• bestEffortDeliver=true pozwala na awaryjne przejście do wykonania tylko w sesji, gdy nie można rozwiązać żadnej zewnętrznej trasy dostarczalnej (na przykład sesje wewnętrzne/webchat lub niejednoznaczne konfiguracje wielokanałowe).
• Końcowe wyniki agent mogą zawierać result.deliveryStatus, gdy żądano dostarczenia, używając tych samych statusów sent, suppressed, partial_failed i failed, które udokumentowano dla openclaw agent --json --deliver.

​

Wersjonowanie

• PROTOCOL_VERSION znajduje się w src/gateway/protocol/version.ts.
• Klienci wysyłają minProtocol + maxProtocol; serwer odrzuca zakresy, które nie obejmują jego bieżącego protokołu. Klienci natywni używają dolnej granicy v3, aby addytywni klienci v4 nadal mogli łączyć się z gateway v3.
• Schematy i modele są generowane z definicji TypeBox:
  • pnpm protocol:gen
  • pnpm protocol:gen:swift
  • pnpm protocol:check

​

Stałe klienta

​

Uwierzytelnianie

• Uwierzytelnianie Gateway współdzielonym sekretem używa connect.params.auth.token albo connect.params.auth.password, zależnie od skonfigurowanego trybu uwierzytelniania.
• Tryby przenoszące tożsamość, takie jak Tailscale Serve (gateway.auth.allowTailscale: true) albo nielokalny gateway.auth.mode: "trusted-proxy", spełniają kontrolę uwierzytelniania połączenia na podstawie nagłówków żądania zamiast connect.params.auth.*.
• Prywatne wejście gateway.auth.mode: "none" całkowicie pomija uwierzytelnianie połączenia współdzielonym sekretem; nie wystawiaj tego trybu na publiczne/niezaufane wejście.
• Po sparowaniu Gateway wydaje token urządzenia ograniczony do roli połączenia
  • zakresów. Jest zwracany w hello-ok.auth.deviceToken i powinien być utrwalony przez klienta na potrzeby przyszłych połączeń.
• Klienci powinni utrwalać główny hello-ok.auth.deviceToken po każdym udanym połączeniu.
• Ponowne łączenie z tym zapisanym tokenem urządzenia powinno także ponownie używać zapisanego zatwierdzonego zestawu zakresów dla tego tokenu. Zachowuje to dostęp do odczytu/próbkowania/statusu, który został już przyznany, i zapobiega cichej redukcji ponownych połączeń do węższego, niejawnego zakresu tylko administracyjnego.
• Składanie uwierzytelniania połączenia po stronie klienta (selectConnectAuth w src/gateway/client.ts):
  • auth.password jest ortogonalne i zawsze jest przekazywane, gdy jest ustawione.
  • auth.token jest wypełniane według priorytetu: najpierw jawny współdzielony token, potem jawny deviceToken, a następnie zapisany token dla danego urządzenia (kluczowany przez deviceId + role).
  • auth.bootstrapToken jest wysyłany tylko wtedy, gdy żaden z powyższych mechanizmów nie wyznaczył auth.token. Współdzielony token albo dowolny wyznaczony token urządzenia go tłumi.
  • Automatyczne promowanie zapisanego tokenu urządzenia podczas jednorazowej ponownej próby AUTH_TOKEN_MISMATCH jest ograniczone tylko do zaufanych punktów końcowych — loopback albo wss:// z przypiętym tlsFingerprint. Publiczne wss:// bez przypięcia się nie kwalifikuje.
• Dodatkowe wpisy hello-ok.auth.deviceTokens są tokenami przekazania bootstrap. Utrwalaj je tylko wtedy, gdy połączenie użyło uwierzytelniania bootstrap na zaufanym transporcie, takim jak wss:// albo parowanie loopback/lokalne.
• Jeśli klient podaje jawny deviceToken albo jawne scopes, ten zestaw zakresów żądany przez wywołującego pozostaje autorytatywny; zakresy z pamięci podręcznej są używane ponownie tylko wtedy, gdy klient ponownie używa zapisanego tokenu dla danego urządzenia.
• Tokeny urządzeń można rotować/odwoływać przez device.token.rotate i device.token.revoke (wymaga zakresu operator.pairing).
• device.token.rotate zwraca metadane rotacji. Powtarza zastępczy token bearer tylko dla wywołań z tego samego urządzenia, które są już uwierzytelnione tym tokenem urządzenia, dzięki czemu klienci używający tylko tokenu mogą utrwalić zamiennik przed ponownym połączeniem. Rotacje współdzielone/administracyjne nie powtarzają tokenu bearer.
• Wydawanie, rotacja i odwoływanie tokenów pozostają ograniczone do zatwierdzonego zestawu ról zapisanego we wpisie parowania tego urządzenia; mutacja tokenu nie może rozszerzyć ani wskazać roli urządzenia, której nigdy nie przyznało zatwierdzenie parowania.
• Dla sesji tokenów sparowanych urządzeń zarządzanie urządzeniami jest samoograniczone, chyba że wywołujący ma także operator.admin: wywołujący niebędący administratorem mogą usuwać/odwoływać/rotować tylko wpis własnego urządzenia.
• device.token.rotate i device.token.revoke sprawdzają także zestaw zakresów docelowego tokenu operatora względem bieżących zakresów sesji wywołującego. Wywołujący niebędący administratorem nie mogą rotować ani odwoływać szerszego tokenu operatora niż ten, który już posiadają.
• Niepowodzenia uwierzytelniania zawierają error.details.code oraz wskazówki odzyskiwania:
  • error.details.canRetryWithDeviceToken (wartość logiczna)
  • error.details.recommendedNextStep (retry_with_device_token, update_auth_configuration, update_auth_credentials, wait_then_retry, review_auth_configuration)
• Zachowanie klienta dla AUTH_TOKEN_MISMATCH:
  • Zaufani klienci mogą podjąć jedną ograniczoną ponowną próbę z tokenem dla danego urządzenia z pamięci podręcznej.
  • Jeśli ta ponowna próba się nie powiedzie, klienci powinni zatrzymać automatyczne pętle ponownego łączenia i pokazać operatorowi wskazówki działania.
• AUTH_SCOPE_MISMATCH oznacza, że token urządzenia został rozpoznany, ale nie obejmuje żądanej roli/zakresów. Klienci nie powinni przedstawiać tego jako błędnego tokenu; poproś operatora o ponowne sparowanie albo zatwierdzenie węższego/szerszego kontraktu zakresu.

​

Tożsamość urządzenia + parowanie

• Węzły powinny zawierać stabilną tożsamość urządzenia (device.id) pochodzącą z odcisku palca pary kluczy.
• Gateway wydaje tokeny na urządzenie + rolę.
• Zatwierdzenia parowania są wymagane dla nowych identyfikatorów urządzeń, chyba że włączone jest lokalne automatyczne zatwierdzanie.
• Automatyczne zatwierdzanie parowania koncentruje się na bezpośrednich połączeniach local loopback.
• OpenClaw ma także wąską ścieżkę samopołączenia lokalną dla backendu/kontenera dla zaufanych przepływów pomocniczych współdzielonego sekretu.
• Połączenia tailnet lub LAN na tym samym hoście nadal są traktowane jako zdalne dla parowania i wymagają zatwierdzenia.
• Klienci WS zwykle dołączają tożsamość device podczas connect (operator + węzeł). Jedynymi wyjątkami operatora bez urządzenia są jawne ścieżki zaufania:
  • gateway.controlUi.allowInsecureAuth=true dla zgodności z niebezpiecznym HTTP tylko na localhost.
  • udane uwierzytelnienie operatora w Control UI przez gateway.auth.mode: "trusted-proxy".
  • gateway.controlUi.dangerouslyDisableDeviceAuth=true (tryb awaryjny, poważne obniżenie bezpieczeństwa).
  • bezpośrednie RPC backendu gateway-client przez loopback, uwierzytelnione współdzielonym tokenem/hasłem Gateway.
• Wszystkie połączenia muszą podpisać nonce connect.challenge dostarczony przez serwer.

​

Diagnostyka migracji uwierzytelniania urządzeń

• Zawsze czekaj na connect.challenge.
• Podpisuj ładunek v2, który zawiera nonce serwera.
• Wyślij ten sam nonce w connect.params.device.nonce.
• Preferowany ładunek podpisu to v3, który wiąże platform i deviceFamily oprócz pól urządzenia/klienta/roli/zakresów/tokenu/nonce.
• Starsze podpisy v2 pozostają akceptowane dla zgodności, ale przypinanie metadanych sparowanego urządzenia nadal kontroluje politykę poleceń przy ponownym połączeniu.

​

TLS + przypinanie

• TLS jest obsługiwany dla połączeń WS.
• Klienci mogą opcjonalnie przypiąć odcisk palca certyfikatu gateway (zobacz konfigurację gateway.tls oraz gateway.remote.tlsFingerprint albo CLI --tls-fingerprint).

​

Zakres

​

Powiązane

• Protokół mostu
• Runbook Gateway