როგორ პასუხობ ავტენტიკაციას Next.js App Router აპლიკაციაში?

Question

Accepted Answer

App Router-ში ავტენტიკაცია მრავალ დონეზე გადაჭიმულია — სესიები, middleware, სერვერის მხარეს შემოწმებები და Server Actions-ის დაცვა. თანამედროვე მიდგომა ამჯობინებს **სერვერის მხარეს სესიის შემოწმებას** მხოლოდ ক্লায়েন্ტის შემოწმებებთან შედარებით. ## რატომ არის მნიშვნელოვანი სესიის სტრატეგია ```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. უხეშ შესაზღვრება middleware-ში (სწრაფი, მაგრამ ეს არ არის მთელი ისტორია) ```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 გაშვებულია Edge-ში ყველა შესაბამისი მოთხოვნამდე — იდეალური იაფი გადამისამართების জამთან. თუმცა, ის უნდა აკეთებდეს მხოლოდ *მსუბუქ* ყოფნის შემოწმებას; ნუ დაეყრდნოთ მას როგორც ერთადერთ ავტორიზაციას (ფუნთუშა შეიძლება არასწორი იყოს). ## 2. სესიის შემოწმება იქ, სადაც ქვენ გამოიყენებთ მონაცემებს (ჭეშმარიტი შესაზღვრება) ```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}

; } ``` ეს სერვერის მხარეს შემოწმება (Server Component-ში) არის **სამსახურო** შემოწმება — ის ფაქტობრივად ავალიდებს სესიას და ჩატვირთავს მომხმარებელს. ## 3. დაცვა Server Actions-სა და 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 არის საჯარო ბოლოდან — **ყოველთვის ხელახლა შეამოწმეთ ავთ და ავტორიზაცია მათში**, აუ დამოუკიდებელი UI-დან შესაზღვრება. ## რატომ გაშლილი შემოწმებები ```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 ``` ## რატომ არის მნიშვნელოვანი Auth App Router-ში არის თავდაცვის სიღრმეში: httpOnly ფუნთუშები (XSS-უსაფრთხო სესიები), middleware სწრაფი გადამისამართებისთვის, და — კრიტიკული — **სერვერის მხარეს შემოწმება ყველა მონაცემების-წვდომა და მუტაციის წერტილში**. ჩვეულებრივი და საშიში შეცდომა არის middleware შემოწმების ან დაფარული კლიენტის UI-ს სამკმელი; ნამდვილი დაცვა სერვერზე სესიისა და ავტორიზაციის დადასტურებიდან მოდის, სადაც მგრძნობიარე მონაცემები იკითხება ან შეიცვლება.