Repository navigation
feat(dev): staging-pinned tailnet previews - #92
Conversation
`npm run dev` talks to production unless the browser toggle says staging, so a preview opened from another device could read and write real user data. `npm run dev:preview` binds to 127.0.0.1 and sets VITE_STAGING_PREVIEW=true. The app is then pinned to staging and calls Supabase at /__staging-supabase on its own origin, which Vite proxies to the staging project. Requests stay same-origin, so Edge Function CORS lists need no preview entries and nothing in production changes. The staging strip shows without the switch to production, and the Settings environment switcher is hidden, since a pinned build cannot switch. The project URLs and anon keys move to a side-effect-free projects.ts so vite.config.ts can import them. The proxy path avoids /supabase because Vite serves supabase/functions/_shared there in dev and the frontend imports it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reachedEnable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. Next included review available in 35 minutes. View limit detailsLimit details: You’ve used the included review currently available. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (14)
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Essentials by visiting https://app.coderabbit.ai/settings/billing. Comment |
|
@coderabbitai review |
|
Started directly with `npm run dev:preview` and then exposed through `tailscale serve`, Vite rejected the forwarded tailnet Host with 403. Only the preview helper's own launcher set the host allowance. vite.config.ts now allows `.ts.net` hosts whenever VITE_STAGING_PREVIEW is on, and only then. Found by the Codex review. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
Local verification at fb8a677: full Review: Copilot is out of quota and CodeRabbit hit its hourly limit, so the Codex reviewer ( |
The dev server listens on 9200-9299 locally, but the browser and staging Auth see the tailnet HTTPS port the preview helper publishes (9100-9149). Say so, and say to publish on 9100-9199 when running `tailscale serve` by hand, since staging Auth only allows `:91*` redirects. Found by the Codex review. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
Codex re-review of 3b90731: one P2, that previews on |
With VITE_STAGING_PREVIEW=true in an .env file, the client pinned itself to the proxy path while vite.config.ts, which only read process.env, installed no proxy, so Auth calls got the SPA HTML. The config now resolves the flag with loadEnv, the same way the client sees it. Found by the Codex review. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
Codex review of b20ee30: one P2. With |
|
@coderabbitai review |
|
|
Codex review ( |
Why
npm run devuses the production Supabase project unless the browser toggle says staging. A preview opened from Adam's phone or Mac over Tailscale could therefore read and write real user data, and sign-in on a preview origin failed anyway.What
npm run dev:previewbinds to127.0.0.1and setsVITE_STAGING_PREVIEW=true.resolveSupabaseConfigpins staging, ignores the toggle, and uses<origin>/__staging-supabaseas the Supabase URL. Vite proxies that path to the staging project (server.proxyandpreview.proxy), so every Supabase call is same-origin: no Edge Function CORS changes, nothing in production changes.src/lib/supabase/projects.tssovite.config.tscan import them./supabase: Vite servessupabase/functions/_sharedat/supabase/...in dev and the frontend imports from there. The first attempt broke the app exactly that way.docs/development.md, a pointer inAGENTS.md, and the staging sign-in note indocs/operations.md.Remote change already made (staging only)
Staging Auth
uri_allow_listgainedhttps://codex-remote.tailab0ab3.ts.net:91*/**so Google sign-in can return to a preview. Production Auth was read, not changed. The previous value is saved on the VPS (~/.codex/backups/debatelab-staging-auth-*/) with undo steps.Evidence
Against a live preview on the tailnet (
https://codex-remote.tailab0ab3.ts.net:9100):/__staging-supabase/auth/v1/settingsthrough the proxy returns byte-identical JSON to staging's own endpoint./,/login,/app: staging strip present, no switch button, 0 requests to the production project, 0 direct requests to staging, no failed requests.POST /__staging-supabase/functions/v1/demo-code-loginreached the staging function and returned its real "Demo code not found." reply.127.0.0.1:9201only.Checks
npm run lint,npm run typecheck,tsc -p tsconfig.node.json,npm run docs:check: pass.npm run verify: result posted as a comment below.🤖 Generated with Claude Code