feat: add dashboard auth, usage resets, and LAN phone access - #1
Merged
Conversation
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Bring the feature branch onto cleaned main after reverting mistaken commits, keeping per-provider usage resets, This month range, Local Mac LAN/phone mode, and related collector/UI hardening.
ctt062
force-pushed
the
feat/dashboard-improvements
branch
from
July 28, 2026 03:06
2742073 to
6a69f88
Compare
Require verified Google/Gmail login before the dashboard, and make npm run setup install a LaunchAgent so Agent Deck starts at login without npm run dev.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What Changed
Risk Assessment
✅ Low: Prior review defects are addressed in source and no new material correctness or security failures were found in the dual-auth, Bearer, and LAN paths.
Testing
Ran the focused unit suite (all green), then exercised a live LAN-bound serve: Google login on loopback, PIN unlock on LAN/mobile, authenticated dashboard with This month selected and per-provider usage resets, plus API month-range payload and LaunchAgent script checks without installing system agents.
/var/folders/cc/l65x8jd574bffvp15g7671j40000gn/T/no-mistakes-evidence/01KYKBJFEAH9DV9GEE5TCJ0F5M/login-google-loopback.png)/var/folders/cc/l65x8jd574bffvp15g7671j40000gn/T/no-mistakes-evidence/01KYKBJFEAH9DV9GEE5TCJ0F5M/login-pin-lan.png)/var/folders/cc/l65x8jd574bffvp15g7671j40000gn/T/no-mistakes-evidence/01KYKBJFEAH9DV9GEE5TCJ0F5M/login-pin-mobile.png)/var/folders/cc/l65x8jd574bffvp15g7671j40000gn/T/no-mistakes-evidence/01KYKBJFEAH9DV9GEE5TCJ0F5M/dashboard-month-usage-resets.png)/var/folders/cc/l65x8jd574bffvp15g7671j40000gn/T/no-mistakes-evidence/01KYKBJFEAH9DV9GEE5TCJ0F5M/dashboard-this-month.png)Evidence: Auth mode + PIN login + month dashboard API transcript
Evidence: Month-range dashboard summary with usage resets
Evidence: LaunchAgent auto-start intent (RunAtLoad/KeepAlive/LAN auth)
Evidence: Server boot confirming Google + PIN auth modes
Pipeline
Updates from git push no-mistakes
⏭️ **intent** - skipped
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
🔧 **Review** - 5 issues found → auto-fixed (3) ✅
README.md:45- Google Identity Services rejects raw IP JavaScript origins (only localhost IPs are exempt; hosts cannot be raw IPs). README and Login still tell users to addhttp://192.168.x.x:3847as an authorized origin, while/api/dashboardrequires Google sign-in and session cookies are host-scoped. Reachable failure: phone opens the LAN URL → login UI → GIS origin rejected → no session → API stays 401. Localhost sign-in cannot help the phone. Fix the product path (e.g. mDNS/HTTPS hostname Google accepts, localhost-only auth with a different phone gate, or document that phone viewing cannot use Google GIS on LAN IPs) and remove the invalid origin instructions.server/index.ts:87-refresh=1forces collector re-read viacollectRaw(force), but usage resets still go throughgetUsageResets()which returnsusageResetsCachefor up to 180s. Clicking Refresh can refresh agent/system/github data while Cursor/Codex/Claude reset windows and used% stay stale. Pass force through and bypass/clear the usage-reset cache on manual refresh.server/collectors/usageResets.ts:166-refreshCodexAccessTokenmay receive a rotatedrefresh_token, then ignores failures when writing~/.codex/auth.json. If OpenAI invalidates the old refresh token and the atomic write fails, Agent Deck keeps a one-shot access token while Codex CLI is left with a dead refresh token. Fail closed: do not treat refresh as success unless persist succeeds, or avoid writing/rotating the user's Codex auth file and only use a read-only access token.scripts/install-launchagent.sh:47- LaunchAgent env parsing exports raw.envvalues, soGOOGLE_CLIENT_ID="....apps.googleusercontent.com"keeps the quotes.dotenvstrips quotes fornpm start, but the plist does not, so the recommendednpm run setuppath can start with a bad client ID and break Google verify while manualnpm startworks. Strip matching single/double quotes when exporting.scripts/install-launchagent.sh:37-npm run setupdefaults LaunchAgentHOSTto0.0.0.0, whileALLOWED_EMAILSremains optional (empty = any verified Google account). Recommended README setup shows an allowlist, but.env.exampleand auth code do not require it. On any origin where GIS works, any Google account can open Mac agent/system/GitHub metrics. Confirm whether allowlist should be required whenever LAN bind is enabled.🔧 Fix: Add PIN LAN auth, Vercel UI, review fixes
3 issues (1 error, 2 warnings) still open:
server/auth.ts:160- Vercel UI → Mac API auth relies on cross-site cookie sessions (SameSite=None; Securewhen Origin is PUBLIC_ORIGIN, pluscredentials:'include'in apiFetch). Reachable failure: open https://agent-dashboard-ctt.vercel.app with VITE_API_BASE/runtime API pointing at an HTTPS Mac tunnel → Google GIS succeeds on Vercel → POST /api/auth/google sets a cookie for the API host → Safari/ITP (and other third-party cookie blocks) drop or refuse that cookie → subsequent /api/dashboard and /api/auth/me stay 401, so the accepted static-UI path cannot stay signed in. Same-origin Mac UI and LAN PIN paths are unaffected. Earliest durable boundary: return a bearer/session token in the login JSON and send it via Authorization from first-party storage on the Vercel origin (or same-site proxy the API under PUBLIC_ORIGIN), instead of depending on third-party cookies.README.md:47- Documented Google JS origins are onlyhttp://127.0.0.1:3847and PUBLIC_ORIGIN, and Login setup copy matches that. CORS already allowlistshttp://127.0.0.1:5174/http://localhost:5174, and the Download/npm run devpath opens port 5174. Reachable failure: follow clone → npm run dev → Google GIS rejects the 5174 origin → no credential → API stays 401. Addhttp://127.0.0.1:5174andhttp://localhost:5174(and localhost:3847 if you keep that host) to README and Login setup instructions.server/auth.ts:313-POST /api/auth/pincompares the PIN with no per-IP/per-session throttle or lockout. With LaunchAgent/serve:lanbinding0.0.0.0, any same-Wi-Fi client can brute-force a short DASHBOARD_PIN and get a full dashboard session. Add a small in-memory rate limit / backoff on failed PIN attempts before issuing the session cookie.🔧 Fix: Add Bearer auth and PIN rate limits
2 warnings still open:
server/auth.ts:132- PIN rate limiting keys off clientIp(), which trusts the first X-Forwarded-For hop, and attachSession enables trust proxy. On the intended LAN bind (HOST=0.0.0.0 / serve:lan) there is no trusted reverse proxy, so any same-Wi-Fi client can rotate X-Forwarded-For on POST /api/auth/pin and never hit the 5-attempt lockout. Reachable failure: brute-force DASHBOARD_PIN despite the new limiter. Earliest fix: key PIN attempts on req.socket.remoteAddress only (ignore XFF/req.ip for this check).vite.config.ts:14- npm run dev:lan proxies /api with changeOrigin: true and does not set X-Forwarded-Host. authModeForRequest prefers x-forwarded-host then Host, so phone GETs to /api/auth/config often see Host=127.0.0.1:3847 and no Origin, returning mode=google. Reachable failure: open the documented Vite LAN URL on a phone → Google GIS UI → raw IP origin rejected (or later POSTs get wrong_auth_mode when Origin is the LAN URL). serve:lan is unaffected. Fix: set changeOrigin: false, or enable xfwd/X-Forwarded-Host so the original LAN Host drives PIN mode.🔧 Fix: Harden PIN rate limit and Vite LAN proxy
✅ Re-checked - no issues remain.
✅ **Test** - passed
✅ No issues found.
npm test(range, lan-intent, auth-mode, bearer-token, pin-rate-limit, types)npm run buildthenHOST=0.0.0.0 PORT=13847serve with Google/PIN envcurl http://127.0.0.1:13847/api/auth/config(google mode)curl -H 'Host: 192.168.13.43:13847' /api/auth/config(pin mode)curl POST /api/auth/pinthenGET /api/dashboard?range=monthwith Bearer tokenChrome CDP screenshots: Google login, LAN PIN login, mobile PIN, authenticated dashboard with This month + usage resetsbash -n scripts/install-launchagent.shand inspect RunAtLoad/KeepAlive/HOST=0.0.0.0 + auth env requirements (no LaunchAgent install)✅ **Document** - passed
✅ No issues found.
✅ **Lint** - passed
✅ No issues found.
✅ **Push** - passed
✅ No issues found.