vrr/openclaw
2
0
Fork 0
mirror of https://github.com/openclaw/openclaw.git synced 2026-10-03 09:39:25 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 30
openclaw/docs/tools/browser/security.md
Vincent Koc 26b84d3f38
docs(tools): split the browser page by reader job (#142984) 
* docs(tools): split the browser page by reader job

docs/tools/browser.md was 55,693 characters across 21 H2 sections mixing
explanation, how-to, reference, and troubleshooting. Move each section into
docs/tools/browser/ and keep /tools/browser as the index.

The split is content-preserving: the nine child pages plus the three blocks
the index still publishes (lede, What you get, Related) reconstruct the
original body byte-for-byte (sha256 a28d5ea4...). Only the four H2 lines that
became child page titles are not reproduced verbatim; each keeps its anchor
on the index.

Every one of the 43 pre-split anchor IDs -- headings, their percent-encoded
and cleaned variants, and the Accordion and Tab titles -- is authored as an
<a id> stub on the index, so existing /tools/browser#... links still resolve.
Per-anchor redirects are not possible: redirectSource() rejects sources
containing [?#].

* docs(tools): retarget cross-references orphaned by the browser split

Eleven link targets, no prose changes. Three were same-page or same-route
anchors inside the moved content: /tools/browser/setup's [Configuration] link
was genuinely broken (its target moved to the configuration page), and the
[Profiles] and [Custom Chrome MCP launch] links resolved only through the
index's anchor stub. The remaining eight are inbound deep links from other
pages, retargeted at the page that now holds the section, matching the
code-mode split precedent.

* docs(i18n): add zh-CN glossary entries for the browser child page titles

check-docs-i18n-glossary requires a source term for every changed doc label.
2026-09-09 18:48:49 +09:00

1.7 KiB
Raw Blame History

summary title read_when
Loopback auth for the browser control API and remote CDP credential handling Browser security
You are reviewing how the browser control API authenticates
You are handling remote CDP tokens

Key ideas:

  • Browser control is loopback-only; access flows through the Gateway's auth or node pairing.
  • The standalone loopback browser HTTP API uses shared-secret auth only: gateway token bearer auth, x-openclaw-password, or HTTP Basic auth with the configured gateway password.
  • Tailscale Serve identity headers and gateway.auth.mode: "trusted-proxy" do not authenticate this standalone loopback browser API.
  • If browser control is enabled and no shared-secret auth is configured, OpenClaw auto-generates and persists a browser-control credential at startup: a token when gateway.auth.mode is none, or a password when it is trusted-proxy (persisted through gateway.auth.password so out-of-process loopback clients can resolve it). Auto-generation is skipped when an explicit string credential is already configured for that mode, or when gateway.auth.mode is password.
  • Configure gateway.auth.token, gateway.auth.password, OPENCLAW_GATEWAY_TOKEN, or OPENCLAW_GATEWAY_PASSWORD explicitly if you want a stable secret you control instead of the generated one.

Remote CDP tips:

  • Prefer encrypted endpoints (HTTPS or WSS) and short-lived tokens where possible.
  • Avoid embedding long-lived tokens directly in config files.
  • Keep the Gateway and any node hosts on a private network (Tailscale); avoid public exposure.
  • Treat remote CDP URLs/tokens as secrets; prefer env vars or a secrets manager.