आप Next.js App Router ऐप्लिकेशन में प्रमाणीकरण को कैसे संभालते हैं?

Question

IT Interview Practice · 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 सार्वजनिक endpoints हैं — **हमेशा उनके अंदर auth और authorization को फिर से जांचें**, चाहे 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 ``` ## यह महत्वपूर्ण क्यों है App Router में Auth गहन सुरक्षा है: httpOnly कुकीज़ (XSS-सुरक्षित सेशन), तेज़ पुनर्निर्देश के लिए middleware, और — महत्वपूर्ण रूप से — **डेटा-एक्सेस और म्यूटेशन के हर बिंदु पर सर्वर-साइड सत्यापन**। आम, खतरनाक गलती middleware जांच या छिपे हुए क्लाइंट UI को पर्याप्त मानना है; असली सुरक्षा सर्वर पर सेशन और प्राधिकरण को मान्य करने से आती है, जहां संवेदनशील डेटा को पढ़ा या बदला जाता है।

सेशन रणनीति

1. Middleware में मोटा गेटिंग (तेज़, लेकिन पूरी कहानी नहीं)

2. उस स्थान पर सेशन की पुष्टि करें जहां आप डेटा का उपयोग करते हैं (असली गेट)

3. Server Actions और Route Handlers को भी सुरक्षित करें

परतों की जांच क्यों करें

यह महत्वपूर्ण क्यों है

संबंधित प्रश्न