ما هو Middleware في Django؟

Question

Accepted Answer

**Middleware** هي إطار عمل من الخطافات التي تعالج **كل طلب واستجابة** بشكل عام، وتقع بين خادم الويب وعروضك (views). يمكن لكل middleware أن تفحص/تعدل الطلبات في الطريق الداخلي والاستجابات في الطريق الخارجي — مثالية للمخاوف المتقاطعة مثل المصادقة وترويسات الأمان والجلسات والتسجيل.

## تدفق الطلب/الاستجابة عبر Middleware

```text
Request  → MW1 → MW2 → MW3 → VIEW
Response ← MW1 ← MW2 ← MW3 ← VIEW

Middleware wraps the view like layers of an onion:
  - on the way IN (request): top-to-bottom
  - on the way OUT (response): bottom-to-top (reverse order)
```

## Middleware المدمج في Django (في settings.py)

```python
MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",          # security headers (HSTS, etc.)
    "django.contrib.sessions.middleware.SessionMiddleware",   # enables request.session
    "django.middleware.common.CommonMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",              # CSRF protection
    "django.contrib.auth.middleware.AuthenticationMiddleware",# enables request.user
    "django.middleware.clickjacking.XFrameOptionsMiddleware", # clickjacking protection
]
# ORDER MATTERS — e.g. SessionMiddleware must come before AuthenticationMiddleware
```

الكثير من وظائف Django الأساسية هي middleware: الجلسات (`request.session`)، والمصادقة (`request.user`)، وحماية CSRF، وترويسات الأمان جميعها تأتي من middleware مدمج. **الترتيب مهم** — بعض middleware يعتمد على تشغيل آخرين أولاً.

## كتابة middleware مخصص

```python
class TimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response          # the next middleware/view

def __call__(self, request):
        # --- code here runs on the way IN (before the view) ---
        import time; start = time.time()

response = self.get_response(request)     # call the next layer (eventually the view)

# --- code here runs on the way OUT (after the view) ---
        response["X-Response-Time"] = f"{time.time() - start:.3f}s"
        return response
```

Middleware هي دالة قابلة للاستدعاء: الكود قبل `self.get_response(request)` يعمل على الطلب، والكود بعده يعمل على الاستجابة. هذا يتيح لك التصرف قبل وبعد تنفيذ العرض.

## الاستخدامات الشائعة لـ Middleware

```text
✓ Authentication / setting request.user
✓ Security headers (CSP, HSTS, X-Frame-Options)
✓ Request/response logging, timing, metrics
✓ Sessions, locale/i18n detection, CORS
✓ Rate limiting, maintenance mode, custom request preprocessing
```

## Middleware مقابل الـ views والديكوريتورز

```text
Middleware → GLOBAL, cross-cutting concerns affecting EVERY (or most) request
Decorators/view logic → per-view concerns specific to certain endpoints
→ Use middleware for app-wide behavior; decorators for selective behavior.
```

## لماذا يهم هذا

Middleware أساسي لكيفية معالجة Django للطلبات — فهمه يشرح كيف تعمل الكثير من وظائف الإطار الأساسية فعلياً ويوفر الآلية الصحيحة للمخاوف المتقاطعة **العامة**.

إدراك أن الجلسات والمصادقة (`request.user`) وحماية CSRF وترويسات الأمان جميعها تأتي من middleware مدمج يزيل الغموض عن معالجة الطلبات في Django ويظهر لماذا تعمل هذه الميزات "فقط". فهم **تدفق الطلب/الاستجابة على شكل طبقات بصلة** (middleware يلف العرض، يعالج الطلبات من الأعلى إلى الأسفل والاستجابات من الأسفل إلى الأعلى) وأن **الترتيب يهم** (بعض middleware يعتمد على آخرين، مثل المصادقة التي تحتاج إلى الجلسات أولاً) مهم لتكوين Django بشكل صحيح وحل المشاكل.

القدرة على **كتابة middleware مخصص** ذات قيمة لتنفيذ السلوك على مستوى التطبيق بنظافة — التسجيل والمراقبة والترويسات المخصصة وتحديد معدل الطلبات وموضع الصيانة — في مكان واحد بدلاً من تكراره عبر الأعراض.

معرفة متى تستخدم middleware (المخاوف العامة التي تؤثر على معظم الطلبات) مقابل الديكوريتورز أو منطق العرض (المخاوف لكل نقطة نهاية) هي قرار معماري رئيسي.

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