Kako rokovati s preveritvijo pristopa v Next.js App Router aplikaciji?

Question

Accepted Answer

Preverjanje pristopa v App Routerju obsega več slojev — seje, middleware, preverjanja na strani strežnika in zaščito Server Actions. Sodoben pristop daje prednost **preverjanju seje na strani strežnika** pred samo preverjanjem na odjemalski strani. ## Strategija seje ```text Cookie-based sessions (httpOnly cookie): ✓ Store a signed session id or encrypted JWT in an httpOnly, secure cookie ✓ httpOnly = not readable by JavaScript → protects against XSS token theft ✓ Use a library: Auth.js (NextAuth), Clerk, Lucia, or a custom solution ``` ## 1. Grobo varovanje v middleware (hitro, vendar ne celotna zgodba) ```ts // middleware.ts — quick check: does a session cookie exist? export function middleware(req: NextRequest) { const session = req.cookies.get("session")?.value; if (req.nextUrl.pathname.startsWith("/dashboard") && !session) { return NextResponse.redirect(new URL("/login", req.url)); } return NextResponse.next(); } ``` Middleware se zažene na Edge-u pred vsako ujeto zahtevo — idealno za poceni preusmeritve. Toda opraviti bi moral le *enostavno* preverjanje prisotnosti; ne zanašajte se nanj kot edino avtorizacijo (piškotek bi bil lahko neveljaven). ## 2. Preverite sejo tam, kjer jo uporabljate (pravi vrata) ```tsx // app/dashboard/page.tsx — verify on the server, in the page itself import { redirect } from "next/navigation"; export default async function Dashboard() { const user = await getCurrentUser(); // validates the session cookie server-side if (!user) redirect("/login"); // authoritative check return

Welcome {user.name}

; } ``` To preverjanje seje na strani strežnika (v Server Component) je **avtoritativna** preverka — dejansko validira sejo in naloži uporabnika. ## 3. Zaščitite tudi Server Actions in Route Handlers ```tsx "use server"; export async function deletePost(id: string) { const user = await getCurrentUser(); if (!user) throw new Error("Unauthorized"); // never trust the caller if (post.authorId !== user.id) throw new Error("Forbidden"); // authorization await db.post.delete({ where: { id } }); } ``` Server Actions so javne končne točke — **vedno ponovno preverite avtentifikacijo in avtorizacijo znotraj njih**, ne glede na varovanje na ravni vmesnika. ## Zakaj plastne preverjave ```text Middleware → fast redirect for the common case (better UX, not security-critical) Server Component/Action → real verification (security boundary) Never rely on hiding UI in the client as a security measure ``` ## Zakaj je to važno Preverjanje pristopa v App Routerju je obrana v globino: httpOnly piškotki (seje varni pred XSS), middleware za hitro preusmerjanje in — kar je ključno — **preverjanje seje na strani strežnika na vsaki točki dostopa do podatkov in sprememb**. Pogosta in nevarna napaka je obravnavanje preverjanja v middleware ali skritega vmesnika kot zadovoljivega; prava zaščita prihaja iz potrditve seje in avtorizacije na strežniku, kjerkoli se berejo ali spreminjajo občutljivi podatki.