كيف تتعامل مع المصادقة في تطبيق Next.js App Router؟

Question

Accepted Answer

المصادقة في App Router تمتد عبر عدة طبقات — الجلسات والبرمجيات الوسيطة والفحوصات من جانب الخادم وحماية 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. البوابة الأساسية في البرمجية الوسيطة (سريعة، لكنها ليست القصة كاملة) ```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(); } ``` تعمل البرمجية الوسيطة على الحافة قبل كل طلب مطابق — مثالية لعمليات إعادة التوجيه البسيطة. لكن يجب أن تقوم فقط بفحص *خفيف الوزن* للوجود؛ لا تعتمد عليها كبوابة التصريح الوحيدة (قد تكون ملف تعريف الارتباط غير صحيح). ## 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 هي نقاط نهاية عامة — **تحقق دائمًا من المصادقة والتصريح داخلها**، بغض النظر عن بوابات مستوى واجهة المستخدم. ## لماذا الفحوصات المتعددة الطبقات ```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 هي دفاع متعدد الطبقات: ملفات تعريف ارتباط httpOnly (جلسات آمنة من XSS)، والبرمجيات الوسيطة لعمليات إعادة التوجيه السريعة، و— الأهم من ذلك — **التحقق من جانب الخادم في كل نقطة وصول بيانات وتغيير**. الخطأ الشائع والخطير هو معاملة فحص البرمجية الوسيطة أو واجهة المستخدم المخفية على أنها كافية؛ الحماية الحقيقية تأتي من التحقق من الجلسة والتصريح على الخادم في كل مكان تُقرأ أو تُغير فيه البيانات الحساسة.