Kuinka toteutat todennusta Next.js App Router -sovelluksessa?

Question

Accepted Answer

Todentaminen App Routerissa kattaa useita tasoja — istunnot, middleware, palvelinpuolen tarkastukset ja Server Actions -suojaus. Moderni lähestymistapa suosii **palvelinpuolen istunnon vahvistusta** pelkkien asiakaispuolen tarkastusten sijaan. ## Istuntostrategia ```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. Pääsy-hallinta middleware-tasolla (nopea, mutta ei koko tarina) ```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 toimii Edge-tasolla ennen jokaista sovitettua pyyntöä — ihanteellinen kevyille uudelleenohjauksille. Se tekee kuitenkin vain *kevyitä* läsnäolo-tarkastuksia; älä luota siihen ainoana valtuutuksena (evuste voisi olla virheellinen). ## 2. Vahvista istunto siellä missä käytät dataa (todellinen pääsy-hallinta) ```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}

; } ``` Tämä palvelinpuolen vahvistus (Server Komponentissa) on **määräävä** tarkastus — se todella validoi istunnon ja lataa käyttäjän. ## 3. Suojaa myös Server Actions ja Route Handlerit ```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 ovat avoimia päätepisteitä — **aina tarkista todentaminen ja valtuutus niiden sisällä**, riippumatta käyttöliittymän tason porttauksesta. ## Miksi kerrostuneet tarkastukset ```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 ``` ## Miksi se on tärkeää Todentaminen App Routerissa on puolustus syvyyden puolesta: httpOnly-evusteet (XSS-turvallinen istuntojen hallinta), middleware nopaille uudelleenohjauksille ja — ratkaisevasti — **palvelinpuolen vahvistus jokaisessa tiedon käyttö- ja muutospisteessä**. Yleinen ja vaarallinen virhe on pitää middleware-tarkastusta tai piilotettua asiakaispuolen käyttöliittymää riittävänä; todellinen suojaus tulee istunnon ja valtuutuksen validoinnista palvelimella kaikkialla, missä herkkiä tietoja luetaan tai muutetaan.