شرح طريقة استخدام Middleware في Django مع أمثلة وأفضل الممارسات

عند بناء تطبيقات الويب باستخدام إطار عمل Django، من الضروري فهم آلية تعامل النظام مع الطلبات (Requests) والردود (Responses) التي تتم بين المستخدم والخادم. واحدة من أهم المكونات التي تلعب دورًا محوريًا في هذه العملية هي ما يعرف باسم Middleware.
يعتبر Middleware بمثابة سلسلة من الطبقات البرمجية الوسيطة التي يتم تنفيذها على الطلب قبل وصوله إلى الطبقة المنطقية (Views)، وأيضًا على الرد قبل إرساله إلى المستخدم النهائي. يوفر هذا المفهوم مرونة عالية للمطورين، حيث يمكنهم إدراج تعليمات برمجية يتم تنفيذها في مرحلة مبكرة أو متأخرة من دورة حياة الطلب.

يكمن السبب الرئيسي في وجود الـ Middleware في الرغبة بتوفير آلية مركزية يمكن من خلالها التحكم في الطلبات والردود بشكل مستقل عن المنطق الأساسي للتطبيق. على سبيل المثال، يمكن استخدام Middleware للتحقق من وجود الجلسات (Sessions)، أو تطبيق إعدادات الأمان، أو التحقق من صلاحيات المستخدم، أو تسجيل العمليات التي تتم على الخادم، أو حتى تعديل محتوى الطلب أو الرد بما يتناسب مع متطلبات التطبيق.

تتميز Django بوجود مجموعة من الـ Middleware الجاهزة التي تأتي مدمجة مع الإطار، مثل SecurityMiddleware، وAuthenticationMiddleware، وCsrfViewMiddleware، والتي توفر وظائف أساسية يحتاجها أي تطبيق ويب احترافي. ومع ذلك، في بعض الأحيان تتطلب طبيعة المشروع تنفيذ معالجات مخصصة لا تغطيها الأدوات الجاهزة، وهنا يأتي دور إمكانية بناء Middleware مخصص يتناسب مع احتياجات التطبيق.

في هذا المقال، سنقوم بشرح فكرة Middleware بشكل مفصل في إطار عمل Django، ونتعرف على كيفية عمله داخل دورة حياة الطلب والرد، ثم نستعرض أهم أنواع Middleware التي يوفرها Django بشكل افتراضي، بالإضافة إلى طريقة إنشاء Middleware مخصص، وأفضل الممارسات التي يجب اتباعها أثناء التعامل مع هذه التقنية. الهدف من هذا المقال هو تمكين المطور من استيعاب الدور الأساسي للـ Middleware في التطبيقات المبنية بـ Django، مع تقديم أمثلة واقعية توضح كيفية الاستفادة منها لتحسين أداء التطبيق وتعزيز مستوى الأمان وتنظيم المعالجة البرمجية.

إذا كنت مطورًا مبتدئًا أو حتى ذو خبرة متقدمة في Django، ففهم آلية عمل Middleware سيمنحك قدرة أكبر على التحكم في التطبيق، ويساعدك على بناء تطبيقات أكثر كفاءة وتنظيمًا، مع الحفاظ على وضوح الكود وتقسيم المهام بشكل منطقي واحترافي.

كيفية عمل Middleware في Django

لفهم آلية عمل Middleware في إطار Django، من الضروري أولًا التعرف على دورة حياة الطلب والرد داخل النظام، لأن الـ Middleware يتوسط هذه الدورة ويتفاعل معها في أكثر من مرحلة. يتكون نظام Django من عدة طبقات متتابعة تبدأ باستقبال الطلب من المستخدم، ثم تمرره إلى مجموعة من المعالجات (Middlewares)، وبعدها إلى منطق المعالجة (Views)، ثم تعيد الرد الناتج إلى المتصفح بنفس الطريقة المعاكسة مرورًا بنفس الـ Middlewares.

عندما يقوم مستخدم بإرسال طلب إلى خادم Django — سواء كان طلبًا لعرض صفحة ويب أو تنفيذ عملية معينة — يتم استلام هذا الطلب بواسطة السيرفر (مثل Gunicorn أو uWSGI) ثم يتم تمريره إلى كائن التطبيق في Django. في هذه اللحظة، يبدأ نظام Django في معالجة الطلب عبر سلسلة من الـ Middlewares المثبتة في إعدادات المشروع داخل متغير MIDDLEWARE في ملف settings.py.
كل Middleware في هذه القائمة يعمل بمثابة محطة يتم فيها تنفيذ تعليمات أو قرارات برمجية تؤثر على الطلب قبل وصوله إلى المنطق الأساسي (View).

تمر دورة العمل عبر مرحلتين أساسيتين:

1. معالجة الطلب (Request Processing)

عند استلام الطلب، يتم تمريره تدريجيًا إلى كل Middleware وفقًا لترتيبه في قائمة MIDDLEWARE. كل Middleware يمكنه التعامل مع الطلب بطرق متعددة، مثل:

• التحقق من إعدادات الأمان.

• إضافة أو قراءة بيانات من الجلسة (Session).

• التحقق من صلاحية المستخدم.

• تعديل كائن الطلب نفسه قبل وصوله إلى الـ View.

• وحتى إيقاف الطلب نهائيًا وإرجاع رد مباشر إلى المستخدم دون الحاجة للوصول إلى الـ View.

على سبيل المثال، يقوم SecurityMiddleware بإجراء فحوصات أمنية مبكرة على الطلب لضمان توافقه مع سياسات الأمان المحددة في إعدادات Django.

2. معالجة الرد (Response Processing)

بعد تنفيذ الـ View ومعالجة المنطق المطلوب وإرجاع الرد (Response)، تبدأ المرحلة العكسية حيث يتم تمرير الرد عبر نفس قائمة الـ Middlewares ولكن بشكل معكوس (من الأخير إلى الأول).
كل Middleware في هذه المرحلة يمكنه:

• تعديل محتوى الرد.

• إضافة رؤوس (Headers) إضافية.

• تسجيل بيانات حول عملية المعالجة.

• تنفيذ أي إجراءات أخرى قبل إرسال الرد إلى المستخدم.

من الأمثلة على ذلك، يقوم CsrfViewMiddleware بفحص الطلبات التي تتطلب حماية ضد هجمات تزوير الطلبات (CSRF) أثناء الطلب، بينما يمكن لـ AuthenticationMiddleware إضافة تفاصيل عن هوية المستخدم إلى كائن الطلب ليستفيد منها الـ View.

طريقة تنفيذ Middleware داخل كلاس

كل Middleware في Django هو في الأصل كلاس (Class) يتبع واجهة محددة يمكن من خلالها تنفيذ عدة دوال اختيارية، أشهرها:

• __init__(self, get_response): يتم تنفيذه مرة واحدة عند تحميل المشروع.

• __call__(self, request): يتم تنفيذه مع كل طلب، ويجب أن يُعيد كائن Response.

• process_view(self, request, view_func, view_args, view_kwargs): يتم تنفيذه قبل استدعاء الـ View.

• process_exception(self, request, exception): يتم تنفيذه عند حدوث استثناء داخل الـ View.

• process_template_response(self, request, response): يتم تنفيذه إذا أعاد الـ View استجابة من نوع TemplateResponse.

في الإصدارات الحديثة من Django (من الإصدار 1.10 فأعلى)، أصبح الشكل الأبسط الموصى به هو أن يحتوي Middleware فقط على دالتي __init__ و __call__، بينما يمكن استخدام باقي الدوال في حال الحاجة لذلك.

ترتيب تنفيذ الـ Middlewares

يتم تنفيذ Middlewares أثناء معالجة الطلب (Request) بنفس ترتيب وجودها في القائمة، وأثناء معالجة الرد (Response) بترتيب عكسي.
بمعنى أن الـ Middleware الأول في القائمة هو أول من يستقبل الطلب، لكنه آخر من يتعامل مع الرد قبل إرساله للمستخدم.

يُعد ترتيب الـ Middlewares من الأمور الحيوية في إعدادات Django، حيث إن بعض Middlewares تعتمد على تنفيذ Middlewares أخرى قبلها أو بعدها. على سبيل المثال، يجب دائمًا أن يتم تنفيذ SecurityMiddleware في البداية لحماية التطبيق مبكرًا من أي طلبات ضارة، بينما من الأفضل تنفيذ AuthenticationMiddleware قبل Middlewares الأخرى التي تعتمد على وجود معلومات المستخدم.

أهم Middleware الافتراضية في Django

يأتي إطار عمل Django مزودًا بمجموعة من الـ Middleware الجاهزة التي يمكن إضافتها أو إزالتها أو إعادة ترتيبها حسب احتياجات المشروع. هذه الـ Middlewares تغطي مجموعة من المهام الأساسية التي يحتاجها أي تطبيق ويب، سواء من حيث الأمان، أو إدارة الجلسات، أو التعامل مع ملفات تعريف الارتباط (Cookies)، أو الحماية من هجمات تزوير الطلبات، أو تسجيل الرسائل، وغيرها.

يتم تعريف الـ Middlewares المستخدمة في أي مشروع Django من خلال المتغير MIDDLEWARE الموجود داخل ملف settings.py. هذه القائمة تتحكم في ترتيب تنفيذ الـ Middlewares أثناء استقبال الطلبات وإرسال الردود، وهو ما يمنح المطور القدرة الكاملة على تخصيص دورة المعالجة بما يتوافق مع طبيعة مشروعه.

فيما يلي نظرة تفصيلية على أهم أنواع الـ Middleware الافتراضية التي يوفرها Django:

1. SecurityMiddleware

يعتبر هذا الـ Middleware من أهم مكونات الأمان في Django، حيث يقوم بتنفيذ عدد من إجراءات الحماية على الطلبات والردود بشكل تلقائي. من أبرز مهامه:

• تفعيل سياسة HTTP Strict Transport Security (HSTS) لإجبار المتصفح على التعامل مع الموقع عبر بروتوكول HTTPS فقط.

• ضبط إعدادات حماية من هجمات Content Sniffing عبر إرسال رأس (Header) X-Content-Type-Options.

• حماية من هجمات Clickjacking عبر إضافة رأس X-Frame-Options.

• تفعيل قيود CORS بناءً على إعدادات المشروع.

وجود هذا Middleware في مقدمة قائمة MIDDLEWARE أمر ضروري لتأمين التطبيق منذ اللحظة الأولى لاستقبال الطلب.

2. SessionMiddleware

يتولى هذا الـ Middleware مسؤولية التعامل مع جلسات المستخدم (Sessions).
بفضله يمكن حفظ بيانات المستخدم بشكل مؤقت في السيرفر أو قاعدة البيانات واستخدامها بين الطلبات المختلفة.
عند تفعيل هذا Middleware، يقوم بإرفاق كائن session إلى كائن الطلب (Request) يمكن من خلاله تخزين واسترجاع البيانات.

مثال:

request.session['user_id'] = 10

3. CommonMiddleware

يوفر هذا Middleware مجموعة من الوظائف الشائعة التي قد يحتاجها أي تطبيق ويب، مثل:

• إعادة توجيه الطلبات إلى النسخة الصحيحة من الرابط (إضافة أو حذف الـ slash).

• منع الوصول إلى روابط تحتوي على حروف كبيرة (إذا كان ذلك مفعّلًا).

• دعم إعدادات التخزين المؤقت (Cache) للصفحات.

4. CsrfViewMiddleware

يوفر هذا Middleware طبقة حماية فعالة ضد هجمات تزوير الطلبات (Cross-Site Request Forgery - CSRF).
يقوم تلقائيًا بفحص كل الطلبات الواردة من نوع POST للتأكد من وجود رمز CSRF صالح، وفي حال عدم توفره يتم منع الطلب وإرجاع استجابة خطأ.

5. AuthenticationMiddleware

يساعد هذا Middleware في ربط كائن المستخدم الحالي بطلبه.
عند تفعيله، يقوم تلقائيًا بقراءة بيانات المصادقة المخزنة في الجلسة (Session) ويضيف كائن user إلى كائن الطلب، مما يمكّن أي View من التعامل مع بيانات المستخدم المصادق عليه.

مثال:

if request.user.is_authenticated:
    # نفّذ إجراءات للمستخدم

6. MessageMiddleware

يتولى هذا Middleware إدارة نظام الرسائل المؤقتة في Django، والذي يُستخدم لعرض رسائل للمستخدمين بعد تنفيذ عمليات معينة، مثل "تم الحفظ بنجاح" أو "حدث خطأ أثناء العملية".
يتكامل هذا Middleware مع نظام الرسائل الموجود في Django ويخزن الرسائل مؤقتًا في الجلسة أو ملفات تعريف الارتباط.

7. XFrameOptionsMiddleware

يوفر هذا Middleware طبقة حماية إضافية ضد هجمات Clickjacking عن طريق إضافة رأس (Header) X-Frame-Options إلى الردود التي يمنع بموجبها عرض الموقع داخل إطارات (Frames) في مواقع خارجية.
يمكن تخصيص هذا الإعداد لتحديد الصفحات المسموح لها بذلك.

ممتاز — سأكمل الآن بكتابة قسم "كيفية إنشاء Middleware مخصص" بنفس الأسلوب التفصيلي المتسلسل.

كيفية إنشاء Middleware مخصص

في كثير من الحالات، قد لا تكون Middlewares الافتراضية التي يوفرها Django كافية لتغطية كافة احتياجات المشروع، مما يضطر المطور إلى بناء Middleware خاص يناسب منطق العمل المطلوب.
يمنحك Django مرونة عالية لإنشاء Middlewares مخصصة يمكنها التدخل في دورة الطلب والرد وتعديلها أو اتخاذ قرارات قبل وبعد معالجة الطلب.

في هذا القسم، سنتعرف بشكل عملي على كيفية إنشاء Middleware مخصص خطوة بخطوة، مع شرح دقيق للدوال المستخدمة وآلية التنفيذ.

1. بنية Middleware في Django

يتكون أي Middleware في Django من كلاس (Class) يستقبل كائن get_response أثناء تهيئة التطبيق، ثم يقوم بتنفيذ دوال محددة مع كل طلب.

الشكل الأساسي لمُعالج Middleware حديث في Django (بدءًا من الإصدار 1.10) يكون كالتالي:

class SimpleMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        # تعليمات يتم تنفيذها قبل الوصول إلى الـ View
        response = self.get_response(request)
        # تعليمات يتم تنفيذها بعد تنفيذ الـ View
        return response

2. مثال عملي: تسجيل وقت تنفيذ الطلب

كمثال عملي، سنقوم بإنشاء Middleware يقوم بحساب الزمن المستغرق لتنفيذ الطلب من لحظة استقباله وحتى إرسال الرد، ثم يقوم بتسجيله في سجل النظام (log).

import time
from django.utils.deprecation import MiddlewareMixin

class ExecutionTimeMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        start_time = time.time()

        # تمرير الطلب إلى باقي Middlewares ثم إلى الـ View
        response = self.get_response(request)

        end_time = time.time()
        execution_time = end_time - start_time

        # تسجيل الزمن في سجل النظام
        print(f"Request executed in {execution_time:.2f} seconds")

        return response

3. إضافة Middleware إلى المشروع

بعد إنشاء الكلاس الخاص بالـ Middleware، يجب إضافته إلى قائمة MIDDLEWARE في ملف settings.py حتى يصبح جزءًا من دورة الطلب والرد.

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    ...
    'myapp.middleware.ExecutionTimeMiddleware',
]

4. التعامل مع Exceptions داخل Middleware

يمكن لأي Middleware التعامل مع الاستثناءات التي قد تحدث أثناء معالجة الطلب.
لتحقيق ذلك، يمكن إضافة دالة process_exception داخل الكلاس:

class CustomExceptionMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        try:
            response = self.get_response(request)
        except Exception as e:
            # التعامل مع الاستثناء
            print(f"Exception caught: {str(e)}")
            from django.http import HttpResponse
            return HttpResponse("حدث خطأ أثناء معالجة الطلب.", status=500)
        return response

5. تنفيذ تعليمات قبل أو بعد View محدد

لو أردت تنفيذ تعليمات قبل تنفيذ View معين فقط، يمكنك استغلال دالة process_view (في الإصدارات القديمة أو باستخدام MiddlewareMixin) أو التعامل مع الطلب داخل __call__ بالتحقق من المسار أو اسم الـ View.

مثال باستخدام request.path:

def __call__(self, request):
    if request.path == '/special-url/':
        print("طلب خاص يتم معالجته هنا.")
    return self.get_response(request)

أفضل الممارسات عند التعامل مع Middleware في Django

عند تطوير تطبيقات ويب باستخدام Django، يعتبر التعامل مع Middlewares جزءًا حساسًا ومؤثرًا في الأداء وأمان النظام واستقراره.
ولهذا السبب، لا ينبغي استخدام هذه المكونات بشكل عشوائي أو دون تخطيط مسبق، بل من الأفضل اتباع مجموعة من الممارسات التي تساعدك على الاستفادة من Middlewares بأقصى كفاءة دون التأثير السلبي على استجابة النظام أو تعقيد منطق العمل.
في هذا الجزء من المقال، سنستعرض أهم النصائح العملية التي ينبغي اتباعها أثناء العمل مع Middlewares في مشاريع Django.

أولى النصائح المهمة هي ضرورة الحفاظ على ترتيب Middlewares بشكل منطقي ومدروس داخل قائمة MIDDLEWARE في ملف الإعدادات.
يتم تنفيذ Middlewares بنفس ترتيبها أثناء استقبال الطلب، ثم بشكل عكسي أثناء إرسال الرد.
بالتالي، وضع Middlewares الأمنية مثل SecurityMiddleware وCsrfViewMiddleware في مقدمة القائمة يضمن أن الطلبات تمر عبر طبقات الأمان قبل أي معالجة أخرى، مما يقلل من احتمالية تسرب طلبات غير موثوقة إلى باقي أجزاء النظام.
بالمقابل، Middlewares التي تتعامل مع الردود أو تقوم بإضافة رؤوس Headers أو تسجيل البيانات في السجلات يمكن وضعها في نهاية القائمة حتى تعمل بعد انتهاء معالجة الطلب في الـ View.

من الممارسات الأساسية التي ينبغي مراعاتها أيضًا هي عدم الإكثار من عدد Middlewares المُضافة إلى المشروع.
رغم أن Middlewares تمنحك مرونة كبيرة في التحكم في الطلبات والردود، فإن زيادة عددها بشكل مبالغ فيه يؤدي إلى إبطاء استجابة التطبيق، لأن كل Middleware يتم تنفيذه بشكل متسلسل على كل طلب، حتى وإن لم يكن ذلك الطلب بحاجة إلى منطق المعالجة الخاص به.
لذلك يُنصح بإضافة Middlewares التي يحتاجها المشروع فعليًا فقط، وإزالة أي Middleware افتراضي لا يلزم منطق عمله أو يمكن تنفيذه داخل View أو Class-based View بشكل أكثر فاعلية وأقل تأثيرًا على الأداء.

عند كتابة Middleware مخصص، من الضروري الالتزام بمسؤولية واحدة (Single Responsibility) داخل كل Middleware.
بمعنى ألا يتولى Middleware واحد تنفيذ أكثر من منطق معالجة أو أداء وظائف متداخلة يصعب تتبعها لاحقًا.
فمثلًا، بدلاً من إنشاء Middleware يقوم بتسجيل بيانات الطلب، ومعالجة الجلسة، والتعامل مع الاستثناءات معًا، من الأفضل تقسيم هذه الوظائف إلى Middlewares مستقلة، كل واحد منها يؤدي مهمة محددة.
هذا الأسلوب يسهل عملية الصيانة، وتحديد مصدر المشكلات، وتحديث منطق العمل عند الحاجة دون التأثير على سلوك Middlewares الأخرى.

كذلك من الجيد تقليل أي عمليات استهلاكية أو زمنية داخل Middleware.
لأن دورة الطلب والرد تمر بكل Middleware، فإن أي عملية استعلام قاعدة بيانات، أو قراءة ملفات، أو عمليات حسابية ثقيلة داخل Middleware تؤثر بشكل مباشر على سرعة استجابة النظام ككل.
في حال كان من الضروري تنفيذ تعليمات معقدة، يفضل الاعتماد على أنظمة خارجية (كالـ Celery Task Queue) أو تنفيذها بعد إرسال الرد للمستخدم، حفاظًا على وقت المعالجة الأساسي للطلب.

مراعاة التعامل مع الاستثناءات داخل Middlewares من الجوانب التي تغفل عنها بعض المشاريع.
عند تصميم Middleware، يجب الحرص على تضمين معالجة متكاملة لأي أخطاء محتملة قد تنتج أثناء تنفيذ الكود الخاص به، حتى لا يتسبب Middleware في إيقاف دورة الطلب أو تعطيل تطبيق بأكمله بسبب استثناء غير متوقع.
إضافة تعليمات try/except في المواضع الحرجة داخل Middleware يساعد في تسجيل الأخطاء بشكل منظم دون التأثير على استجابة الطلب أو المستخدم.

كذلك من الممارسات الاحترافية التي تحسّن من جودة Middlewares الاعتماد على إعدادات المشروع (Settings) عند تصميم Middleware مخصص.
بدلاً من تثبيت قيم ثابتة Hardcoded داخل Middleware، يمكن تعريف المتغيرات والإعدادات الخاصة به داخل ملف settings.py، ثم قراءتها من خلال django.conf.settings.
هذا الأسلوب يسهل تعديل منطق Middleware لاحقًا دون الحاجة لتغيير الكود، ويسمح بتخصيص السلوك حسب بيئة العمل (تطوير - تشغيل - اختبار).

أخيرًا، من الضروري كتابة اختبارات آلية (Unit Tests) تغطي Middlewares المخصصة ضمن اختبارات المشروع.
نظرا لأن Middlewares تتعامل بشكل مباشر مع الطلبات والردود، وأحيانًا مع الجلسات والمصادقة والأمان، فإن أي خلل فيها قد يؤدي إلى تعطل النظام أو كشف ثغرات أمنية.
لذلك يوصى بكتابة اختبارات تتأكد من سلوك كل Middleware في ظروف الطلب المختلفة، بما في ذلك طلبات المصادقة، الطلبات غير المصرح بها، الطلبات المعطوبة، والردود المتوقعة.