Logan CusanoandClaude Opus 5
c7f985df42
Frontend half of SAAS_PLAN.md B2/B3. The backend commits so far (org_id
stamping, Firestore rules) don't protect anything by themselves - every
hook in lib/use*.ts reads Firestore directly from the browser
(onSnapshot(collection(db, ...))), which is why B1's rules commit called
this out as the actual read path in the first place. Until these hooks
filter by org_id, the rules just turn "any signed-in user sees everything"
into "any signed-in user sees nothing" the moment they're deployed, because
nothing supplies the org_id the rules now require.
useCalls (all three exports), useIncidents (useIncidents +
useActiveIncidents), useNodes, useSystems, and useAlerts (both exports) now
pull orgId from AuthProvider and add where("org_id","==",orgId) to their
query. If orgId is falsy - not yet resolved, or the account genuinely has
no org - each hook returns empty rather than falling back to an unfiltered
query, which would silently reopen the exact leak this closes for anyone
whose claim hasn't loaded yet. useIncident/useNodes single-doc-by-id reads
and useTrips are intentionally untouched: single-doc reads are already
covered by the rules directly, and trips has no org_id at all (see the
previous commit's trips.py gating - it's staying founding-org-only via B7,
not becoming tenant-scoped).
AuthProvider grew orgId/orgRole state (read from the org_id/org_role custom
claims POST /auth/signup sets) and a refreshClaims() escape hatch for the
signup flow to force a claims refetch after provisioning. The load-bearing
change is in when it sets the drb_session cookie: only when a claim carries
org_id. A signed-in user with no org - the accidental-signup hole
SAAS_PLAN.md 2.2/2.3 flagged, where Google sign-in on /login auto-creates a
Firebase account with no role or org claim at all - now gets no cookie,
which starts them at "no data, by construction" rather than "viewer role,
full read access" once combined with the rules deployed earlier.
ChromeSwitcher carries the other half of that guard: a signed-in user with
no orgId, anywhere outside the marketing pages, gets redirected to
/onboarding (added to the frontend in the next commit) instead of letting
every page's data hooks just quietly return empty forever. middleware.ts
adds /signup and /onboarding to a new no-cookie-gate list, since
AuthProvider's cookie logic means an unprovisioned user by definition has
no drb_session cookie - gating those two routes on it would bounce exactly
the users who need them back to /login before the client-side redirect
above ever runs. /terms and /privacy (next-next commit) are pre-added to
both PUBLIC_PATHS and ChromeSwitcher's MARKETING_PATHS here so that commit
doesn't need to touch routing files.
Typecheck: clean (tsc --noEmit via the WSL-native ~/drb-frontend copy).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
44 lines
1.8 KiB
TypeScript
44 lines
1.8 KiB
TypeScript
import { NextRequest, NextResponse } from "next/server";
|
|
|
|
// Public marketing pages — no session required. Keep this in sync with
|
|
// MARKETING_PATHS in components/ChromeSwitcher.tsx (that one picks page
|
|
// chrome; this one decides whether to redirect at all).
|
|
const PUBLIC_PATHS = new Set(["/", "/features", "/pricing", "/faq", "/terms", "/privacy"]);
|
|
|
|
// /signup and /onboarding are deliberately NOT gated by the drb_session
|
|
// cookie here, even though they aren't "public" in the sense of not needing
|
|
// an account — AuthProvider only sets that cookie once a user has an org_id
|
|
// claim (SAAS_PLAN.md B3's no-claim guard), and /onboarding exists
|
|
// specifically for a signed-in user who doesn't have one yet. Gating it on
|
|
// the same cookie would bounce the exact users who need it back to /login
|
|
// before ChromeSwitcher's client-side redirect ever runs. Both pages do
|
|
// their own client-side auth check (redirect to /login if genuinely signed
|
|
// out) instead.
|
|
const NO_SESSION_COOKIE_GATE = new Set(["/signup", "/onboarding"]);
|
|
|
|
// NOTE: this is a UX redirect only, not a security boundary — it just checks
|
|
// a client-set cookie's presence. Real enforcement is server-side, in
|
|
// drb-c2-core/app/internal/auth.py. See CLAUDE.md.
|
|
export function middleware(request: NextRequest) {
|
|
const session = request.cookies.get("drb_session");
|
|
const { pathname } = request.nextUrl;
|
|
|
|
if (PUBLIC_PATHS.has(pathname) || NO_SESSION_COOKIE_GATE.has(pathname)) {
|
|
return NextResponse.next();
|
|
}
|
|
|
|
if (pathname === "/login") {
|
|
if (session) return NextResponse.redirect(new URL("/dashboard", request.url));
|
|
return NextResponse.next();
|
|
}
|
|
|
|
if (!session) {
|
|
return NextResponse.redirect(new URL("/login", request.url));
|
|
}
|
|
return NextResponse.next();
|
|
}
|
|
|
|
export const config = {
|
|
matcher: ["/((?!_next/static|_next/image|favicon\\.ico).*)"],
|
|
};
|