Add protected auth flow for remote web access

[lamhoangtung]

What Changed

In built web mode, --auth-token now protects both HTTP routes and WebSocket connections instead of only gating the socket handshake.

Unauthorized browser requests now render a dedicated sign-in page. Tokenized links like /?token=... are accepted once, stored in an auth cookie, and redirected to a clean URL without the token. This also adds form-based token entry, stale-cookie invalidation after token changes, origin checks for cookie-authenticated WebSocket upgrades, startup/browser-open handling for protected links, and docs/tests covering the remote access flow.

Why

Previously, remote protection in web mode was incomplete: a token was required for the WebSocket connection, but the HTTP app surface was still reachable without authentication. That made the security model inconsistent and awkward for real remote access, especially on phones or shared links.

This change makes built web mode behave like users expect: the token gates access to the whole app, not just the live session channel. The tokenized-link-to-cookie flow keeps first-time access simple while removing the token from the URL after login and re-prompting cleanly when the token rotates.

Related issues:

• Fixes #257
• Addresses #227

UI Changes

This PR adds a dedicated protected sign-in page for built web mode.

Before:

• No protected entry page for unauthorized browser requests.

After:

• A branded sign-in page with token entry and invalid-token feedback, followed by redirect back to the requested path after successful auth.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

High Risk
Touches authentication for both HTTP routing and WebSocket upgrades in web mode; regressions could lock users out or unintentionally expose the UI if the new checks are incorrect.

Overview
In built web mode, --auth-token now protects the full HTTP surface (not just the WebSocket handshake): unauthorized document requests return a new sign-in page, and non-document routes return 401 Unauthorized.

Introduces a token-to-cookie flow: visiting /?token=... sets an HttpOnly auth cookie and redirects to a clean URL, plus POST /auth/login for manual token entry and stale-cookie invalidation when the server token changes.

WebSocket upgrades in protected web mode accept either a query token or a valid auth cookie, with an added Origin/Host match requirement for cookie-authenticated upgrades. Startup behavior is updated to log/auto-open a tokenized share URL when protection is enabled (skipping tokenization in dev-url mode and keeping wildcard hosts opening on localhost).

^{Written by Cursor Bugbot for commit 822c094. This will update automatically on new commits. Configure here.}

Note

Add protected auth flow for remote web access with token-based cookies and WebSocket gating

• Adds a new webAuth.ts module with helpers for cookie management, auth state evaluation, HTML auth page rendering, and request utilities.
• HTTP requests in built web mode with an auth token now require authentication: unauthorized HTML requests receive a login page (401), other routes receive plain Unauthorized; valid token in query sets an auth cookie and redirects to a clean URL; POST /auth/login accepts a token form submission and sets the cookie.
• WebSocket upgrades in protected web mode accept either a token query parameter or a valid auth cookie with a matching Origin host, rejecting stale or mismatched-origin cookies.
• On startup, the server auto-opens and logs a tokenized URL when protected web auth is enabled; wildcard host bindings still target localhost; dev server URLs skip tokenization.
• Risk: existing clients accessing the web UI or WebSocket without a token or cookie will receive 401 responses after this change.

^{Macroscope summarized 822c094.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 615c0bc2-5ce9-4c92-9951-ee57023851f5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}