Skip to content

The /panel/dash reverse proxy is unauthenticated by necessity — needs a designed gate #9

Description

@mabry1985

Gap

PR #8 gated /shot + /nav, but the full-mode /panel/dash HTTP+WS reverse proxy (→ the local agent-browser dashboard, i.e. live viewport + control) must stay on the public prefix today: it's loaded by an <iframe>, and an iframe navigation can't carry an Authorization bearer. On a token-gated deployment that leaves interactive browser control reachable without the bearer.

Options

  1. Short-lived signed cookie minted by a gated route (POST /api/plugins/agent_browser/dash-session → sets a scoped, expiring cookie the proxy checks). The page calls it via the kit's apiFetch before setting the iframe src.
  2. One-time token in the iframe URL, minted the same way (weaker — lands in logs/history, but expiry bounds it).
  3. Ride protoAgent's WS-upgrade-through-the-hub work (protoAgent#883) if a console-level gated embed channel emerges from it.

Option 1 is the standard pattern and fits the kit handshake timing.

Context

Found in the protoAgent plugin-ecosystem audit (2026-06-12). Same constraint class as plugin PAGES being public (a page-load can't carry a bearer) — but the dash proxy is interactive control, not chrome, so it deserves a real gate.

🤖 Filed by Claude Code (plugin-ecosystem audit)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions