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

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions