Sharing a remote link gave the recipient the dashboard's real credential.
`/remote-login?rt=…` validated the remote token and then redirected to
`/?token=<daemonToken>` — so the daemon token landed in their URL bar, their
history, and anything that logs URLs. It also made the separate remote token
pointless: revoking it left the recipient permanently authenticated, because
they were holding the daemon token itself, not the remote one.
A validated remote token now mints an opaque, expiring, revocable session
(createRemoteSessionStore) returned as an HttpOnly, SameSite=Lax cookie (Secure
over https, which a quick tunnel always is), and the redirect carries nothing
sensitive. The auth middleware gains a third credential source, checked only
after the daemon token and only when a validator is installed, so the existing
header and fn_token paths and their constant-time comparison are untouched.
Session TTL is capped by the remote token's own remaining life when it is
short-lived — a 15-minute share link must not buy a longer stay through the back
door — and otherwise uses the configured shortLived.ttlMs (default 15m). Sessions
are in-memory on purpose: a restart invalidating them fails in the safe
direction, and persisting would write a credential to disk for no benefit.
A source-level ratchet asserts the handler never puts the daemon token in a
redirect again; verified it fails when the old line is reinstated, since the leak
was one line and far easier to reintroduce than to notice.
Also: POST /api/remote/tunnel/start answered {state:"starting"} when no engine
was attached, so the UI showed a tunnel coming up that never would, settling to
stopped with lastError:null and no way to tell it from a broken one (hit live in
a container whose launch dir is not the registered project — unscoped requests
fall back to a store with no engine). It stays 200 and idempotent, because a
dashboard legitimately runs --no-engine, but now reports the truth: stopped, with
REMOTE_TUNNEL_ENGINE_UNAVAILABLE naming the ?projectId= fix.
63 dashboard remote/auth tests pass, including 11 new ones.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0e7c353f2b