Logan CusanoandClaude Opus 5
be79499635
Three of the app's routes were referenced but never existed, so the redesign's
navigation pointed at 404s from several directions.
/dashboard was the post-login and fallback redirect target in nine places --
login, onboarding, middleware, the admin/nodes/systems/tokens/settings guards,
and the marketing header -- but app/dashboard/ was never created. Signing in
normally dropped the user on a 404. The real signed-in home is "/", which
app/page.tsx already renders as LiveView for an authed user with an org, and
which the nav labels "Live"; all nine now point there.
Nav also linked /watch and /network, neither of which existed. /watch is the
alerts screen under its redesign name, so it re-exports app/alerts/page.tsx
and /alerts stays reachable for old links. /network is new: the "my equipment"
hub the redesign moved /nodes, /systems and /tokens behind and then never
built, which had left /systems and /tokens with no entry point in the UI at
all. Its hooks all run before the admin/operator guard, per d041c86.
Separately, the admin page's guard read isAdmin without authLoading, so every
cold load of /admin -- typed URL, hard refresh, bookmark -- redirected away
while the Firebase claims were still resolving. Admin was only reachable by
clicking through from an already-mounted page. Now it waits, like every other
guarded route does.
And /incidents no longer lies about an empty list: a failed Firestore query
leaves `incidents` empty just as a quiet night does, and the page was printing
"No incidents recorded yet" over the top of a missing-composite-index error.
useIncidents already returned `error`; the page just ignored it. It now renders
an ErrorBanner instead, so the undeployed indexes in server-26#13 read as a
failure rather than as silence on the radio.
Closes server-26#30, server-26#31. server-26#13 stays open -- the rules and
indexes still have to be pushed to the live project by hand.
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("/", 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).*)"],
|
|
};
|