Hero Sheet bybear.dk

← Roadmap

#4 · Platform · 2026-05-10

Authentication and Google login

Status: Shipped

Platform

Implementation

  • Deliver sign-in so each user has a stable identity (Firebase Auth UID) for sheets, sync, and Firestore rules; Google provider first, architecture leaves room for more providers later.
  • Client: Firebase Auth with Google provider, sign-in and sign-out UX, sensible loading and error states; responsive and touch-friendly per AGENTS.md.
  • Sign-out uses the Firebase client SDK (e.g. signOut) as the simple default; drive UI from auth state listeners, including multiple tabs—no separate server session to revoke unless a future design adds one.
  • Persistence and “session shape” follow the Firebase Auth Web SDK and official docs (how credentials and ID tokens are stored and refreshed); server-side verification uses Admin SDK patterns Firebase recommends for SvelteKit-style requests—no bespoke parallel cookie session unless the Firebase guide requires it.
  • Server: verify Firebase ID tokens on protected SvelteKit paths or server loads (Admin SDK or equivalent); single source of truth for “who is this request” before any user data access.
  • Coordinate with task
  • Firestore security rules, UID field conventions, and any custom claims timeline are decided with task
  • First slice is Google only; defer email magic link, anonymous auth, and account linking until product asks for them.
  • No separate Firebase cloud project for staging: Vercel deploys and production use the production Firebase project for Auth and data; typical interactive local dev can stay on that same project for dogfooding.
  • Hosting is Vercel (production and preview URLs); production traffic is served at https://herosheet.bybear.dk. Auth, Firestore, and related backend infra live in that same production Firebase project—console authorized domains must cover at least localhost and that hostname; preview hosts stay TBD until the deploy workflow is clear.
  • Origin defaults for Auth config: local dev at http://localhost:5173; production at https://herosheet.bybear.dk (standard port 443). Match authorized domains and OAuth redirect URIs in Firebase and Google Cloud to those origins first; extend to Vercel preview URLs only after the team decides how previews should authenticate.
  • Automated tests and CI must not read or write production Firestore or production Auth user data; use only the Firebase Auth and Firestore emulators for those runs with env or harness wiring that never points tests at prod.
  • How tests seed and clear Auth users and Firestore documents in the emulators is undecided until integration tests need it; settle then so runs stay isolated without touching prod.
  • CI specifics for starting the Auth and Firestore emulators, waiting until healthy, teardown, timeouts, and parallel job layout are implementation details to decide when CI is wired—not planning blockers for the task brief.
  • Document env layout (public config vs secrets): production-oriented vars for runtime, emulator endpoints and project IDs for test/CI, and how to start or script the emulator suite locally and in CI—concrete variable names and client/Admin SDK hooks for “emulator vs production” are chosen during implementation and written up then, not nailed down in this brief.
  • Firebase App Check and similar abuse-rate controls are out of scope for this slice; add a follow-up task when hardening against scripted clients matters.
  • Implementation note: the stack uses Firebase **session cookies** (Admin `createSessionCookie`) synced from the client ID token after Google sign-in. That matches Firebase’s SSR guidance so `hooks.server.ts` can resolve `locals.user` without a bespoke parallel session format. Client sign-out still calls Firebase `signOut`; the client also `DELETE`s `/api/auth/session` so the http-only cookie clears. See internal report `task-004-google-auth` for detail.

Questions

  • Server-only Firebase Admin SDK: where does the service account credential live for local dev (file path, env var, or other) versus CI (e.g. encrypted secret), and what build or code checks prove it cannot be imported into client bundles?
  • If the service account key is rotated or leaked, what steps reissue credentials, update every environment, and validate deploys without downtime surprises?