mirror of
https://github.com/openclaw/openclaw.git
synced 2026-07-09 14:14:02 +00:00
654029892d
* feat(browser): direct extension→gateway relay path for remote Chrome (#53599) Let the OpenClaw Chrome extension pair directly to a remote gateway over wss:// with no OpenClaw node host on the browser machine — the managed-hosting path from #53599 (extension is the only thing installed on the laptop). - Gateway route /browser/extension registered by the browser plugin with auth:"plugin" + no nodeCapability, so the gateway does not pre-enforce token auth (browser WebSockets cannot send an Authorization header). The upgrade handler self-validates the host-local relay secret from ?token=, origin-checks chrome-extension://, resolves the extension profile, then attaches the socket to the same ExtensionRelayBridge the loopback relay uses. All CDP synthesis, tab-group scoping, and the in-process Playwright /cdp client are unchanged. - `openclaw browser extension pair --gateway-url wss://host` prints a wss://host/browser/extension#<secret> string; the path ends in /extension so the extension's existing pairing parser accepts it with zero extension code changes. - relay-server: extract attachExtensionWebSocket + export requestToken / isAllowedExtensionOrigin / EXTENSION_RELAY_MAX_PAYLOAD_BYTES so loopback and gateway paths share one bind + one frame cap. - runtime-lifecycle: dispose the shared gateway WebSocketServer on shutdown. - docs: three remote topologies (same host / direct-to-gateway / via node host). Coverage: 6 unit tests for the handler's path/503/403/404/401/attach branches. The full extension→bridge→CDP→Chrome loop over /browser/extension was live-proven with a real Chrome + the built extension. The real gateway upgrade→handleUpgrade dispatch for an auth:"plugin" unprotected route is verified against core (server-http.ts, plugins-http.ts, route-auth.ts). * fix(browser): harden remote extension pairing