Logan CusanoandClaude Opus 5
1b4ed0d09c
SAAS_PLAN.md B5/B6, narrowed: no Stripe/pricing/tier work of any kind this pass (a mid-build correction from the business side landed while this was in progress - the commercial model, SAAS_PLAN.md section 6.1, is still undecided), so app/pricing and lib/billing.ts's PLANS are untouched here. What's left of B5/B6 without that - real legal pages and a working waitlist - still ships. app/terms/page.tsx and app/privacy/page.tsx are section scaffolding, not legal text. Every section is a TODO(legal) note describing what that section needs to cover, and the page leads with a "Draft - not yet in force" banner. This isn't caution for its own sake: DRB records, stores, and transcribes public-safety radio traffic, and recording/rebroadcast legality varies by state (SAAS_PLAN.md section 6.3) - an agent-generated draft here would be actively wrong to publish, not just unpolished. Both were pre-added to middleware.ts's PUBLIC_PATHS and ChromeSwitcher's MARKETING_PATHS two commits ago; MarketingFooter now links both. app/waitlist/page.tsx is a real, working form against the already-shipped POST /waitlist - email + optional org name/note, no plan or price mentioned anywhere on it, matching the backend route's own scope (rate limited by source IP, not coupled to any tier). Linked from MarketingFooter as "Request access," not from the pricing page - pricing CTAs stay exactly as they were. 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", "/waitlist"]);
|
|
|
|
// /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).*)"],
|
|
};
|