vultr/openclaw
1
0
Fork 0
mirror of https://github.com/openclaw/openclaw.git synced 2026-05-06 11:40:42 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(gateway): decouple backend RPC from CLI pairing

Browse Source
This commit is contained in:
Peter Steinberger
2026-04-25 23:22:08 +01:00
parent 91adb69c57
commit e640c0a95f
7 changed files with 175 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/gateway/protocol.md
View File

@@ -110,6 +110,14 @@ permissions:
}
```
Trusted same-process backend clients (`client.id: "gateway-client"`,
`client.mode: "backend"`) may omit `device` on direct loopback connections when
they authenticate with the shared gateway token/password. This path is reserved
for internal control-plane RPCs and keeps stale CLI/device pairing baselines from
blocking local backend work such as subagent session updates. Remote clients,
browser-origin clients, node clients, and explicit device-token/device-identity
clients still use the normal pairing and scope-upgrade checks.
When a device token is issued, `hello-ok` also includes:
```json

5
docs/gateway/security/index.md
View File

@@ -92,6 +92,11 @@ Treat Gateway and node as one operator trust domain, with different roles:
- **Gateway** is the control plane and policy surface (`gateway.auth`, tool policy, routing).
- **Node** is remote execution surface paired to that Gateway (commands, device actions, host-local capabilities).
- A caller authenticated to the Gateway is trusted at Gateway scope. After pairing, node actions are trusted operator actions on that node.
- Direct loopback backend clients authenticated with the shared gateway
token/password can make internal control-plane RPCs without presenting a user
device identity. This is not a remote or browser pairing bypass: network
clients, node clients, device-token clients, and explicit device identities
still go through pairing and scope-upgrade enforcement.
- `sessionKey` is routing/context selection, not per-user auth.
- Exec approvals (allowlist + ask) are guardrails for operator intent, not hostile multi-tenant isolation.
- OpenClaw's product default for trusted single-operator setups is that host exec on `gateway`/`node` is allowed without approval prompts (`security="full"`, `ask="off"` unless you tighten it). That default is intentional UX, not a vulnerability by itself.

6
docs/gateway/troubleshooting.md
View File

@@ -200,6 +200,12 @@ Use `error.details.code` from the failed `connect` response to pick the next act
| `AUTH_DEVICE_TOKEN_MISMATCH` | Cached per-device token is stale or revoked. | Rotate/re-approve device token using [devices CLI](/cli/devices), then reconnect. |
| `PAIRING_REQUIRED` | Device identity needs approval. Check `error.details.reason` for `not-paired`, `scope-upgrade`, `role-upgrade`, or `metadata-upgrade`, and use `requestId` / `remediationHint` when present. | Approve pending request: `openclaw devices list` then `openclaw devices approve <requestId>`. Scope/role upgrades use the same flow after you review the requested access. |
Direct loopback backend RPCs authenticated with the shared gateway
token/password should not depend on the CLI's paired-device scope baseline. If
subagents or other internal calls still fail with `scope-upgrade`, verify the
caller is using `client.id: "gateway-client"` and `client.mode: "backend"` and
is not forcing an explicit `deviceIdentity` or device token.
Device auth v2 migration check:
```bash