ارتكبتُ ثلاثة أخطاء مكلفة في المصادقة (Auth) مع Next.js 16
لقد أخطأتُ في إعداد proxy.ts matcher في ثلاثة مشاريع مختلفة.
الجزء الأسوأ؟ لم تظهر أي أخطاء. لا تحذيرات. لا سجلات (logs). بدا كل شيء مثاليًا حتى ظهرت الثغرات الأمنية.
قام Next.js 16 بتغيير middleware.ts إلى proxy.ts. هذا ليس مجرد تغيير في الاسم، بل هو تحول جذري في كيفية التعامل مع الطلبات (requests).
إليك ما يجب أن تعرفه لتجنب تعطل نظام المصادقة (auth) الخاص بك.
القواعد الجديدة كان الـ middleware مربكًا. استخدمه المطورون لإجراء استدعاءات لقواعد البيانات والعمليات المنطقية الثقيلة، لكن هذا ليس دوره.
يعمل الـ proxy عند حدود الشبكة، حيث يقوم باعتراض الطلبات قبل وصولها إلى مساراتك (routes).
- يعمل على Node.js بشكل افتراضي، وليس على Edge runtime.
- ستحصل على دعم كامل للتشفير (crypto).
- يمكنك استخدام أي مكتبة JWT قياسية دون الحاجة إلى حلول بديلة.
الفشل الصامت
إذا قمت بترقية Next.js دون استخدام codemod، فقد يظل ملف middleware.ts القديم موجودًا في مشروعك. سيتجاوز فحوصات TypeScript وسيعمل الـ compilation بشكل طبيعي.
لكنه لن يفعل شيئًا.
لن تعمل عمليات إعادة التوجيه (redirects)، ولن تعمل المصادقة (auth). سيتجاوز تطبيقك ببساطة طبقة الأمان بصمت.
تحقق من هذه الأشياء الثلاثة يدويًا:
- تأكد من وجود
proxy.tsفي جذر المشروع (project root). - تأكد من أن الدالة المصدرة (exported function) تسمى
proxyوليسmiddleware. - احذف ملف
middleware.tsالقديم تمامًا.
فخ الـ Matcher تتعطل معظم إعدادات المصادقة في تكوين الـ matcher. إذا لم تستثنِ الملفات الثابتة (static files)، فسيتم تشغيل الـ proxy على كل ملف CSS و JS، مما يؤدي إلى حلقات إعادة توجيه لا نهائية (infinite redirect loops) على الملفات المساعدة (assets).
استخدم negative lookahead لاستثناء:
_next/static_next/image- الأيقونات (favicons) وخرائط الموقع (sitemaps)
- امتدادات الصور (png, jpg, svg)
تحذير: لا تثق بالـ Headers وحدها هنا وقعتُ في الخطأ.
يقوم الـ proxy بضبط رؤوس (headers) مثل x-user-id في الطلب. وتقوم مكونات الخادم (Server Components) بقراءتها عبر headers().
إذا كان هناك ثغرة في الـ matcher الخاص بك، فيمكن للمستخدم إرسال رأس x-user-id الخاص به. لا تستطيع مكونات الخادم (Server Component) التمييز بين الرأس الذي وضعه الـ proxy والرأس الذي أرسله العميل (client).
يمكن للمهاجم تزييف (spoof) معرف المستخدم (user ID) في مسار غير مطابق (unmatched route). قد لا يتمكنون من رؤية البيانات، لكن قد يحصلون على صلاحيات لا ينبغي أن يمتلكوها.
الحل: الـ proxy هو بوابتك السريعة، حيث يتولى المهام الثقيلة عند الـ edge.
ولكن يجب عليك التحقق من الـ JWT مرة أخرى داخل مكونات الخادم (Server Components) الخاصة بك.
- يقوم البروكسي بإيقاف معظم الجهات الضارة بسرعة.
- يقوم فحص مكون الخادم (Server Component) بسد الثغرة في حال فشل المطابق (matcher).
التكرارية هي الأمان.