Ce este middleware în Django?

Question

Accepted Answer

**Middleware** este un framework de hook-uri care procesează **fiecare request și response** la nivel global, situandu-se între serverul web și views-urile tale. Fiecare middleware poate inspecta/modifica request-urile pe cale de intrare și response-urile pe cale de ieșire — ideal pentru probleme transversale cum ar fi autentificarea, header-urile de securitate, sesiunile și logging-ul.

## Fluxul request/response prin 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-ul încorporat al Django (în 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
```

Multe dintre funcționalitățile de bază ale Django sunt middleware: sesiunile (`request.session`), autentificarea (`request.user`), protecția CSRF și header-urile de securitate provin toate din middleware-ul încorporat. **Ordinea contează** — unele middleware-uri depind de alte middleware-uri care rulează mai întâi.

## Scrierea middleware-ului personalizat

```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
```

Un middleware este un callable: codul înainte de `self.get_response(request)` rulează pe request, codul după rulează pe response. Acest lucru te permite să acționezi atât înainte, cât și după execuția view-ului.

## Utilizări frecvente de 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 vs views/decoratori

```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.
```

## De ce contează

Middleware-ul este fundamental pentru modul în care Django procesează request-urile — înțelegerea acestuia explică cum funcționează de fapt o mare parte din funcționalitatea de bază a framework-ului și oferă mecanismul potrivit pentru **probleme globale și transversale**.

Recunoașterea faptului că sesiunile, autentificarea (`request.user`), protecția CSRF și header-urile de securitate provin toate din middleware-ul încorporat demistifică procesarea request-urilor în Django și arată de ce aceste caracteristici "pur și simplu funcționează". Înțelegerea **fluxului de cerință/răspuns în straturi de ceapă** (middleware înconjoară view-ul, procesând request-urile de sus în jos și response-urile de jos în sus) și că **ordinea contează** (unele middleware-uri depind de altele, cum ar fi autentificarea care necesită sesiuni mai întâi) este importantă pentru configurarea corectă a Django și depanarea problemelor.

Capacitatea de a **scrie middleware personalizat** este valoroasă pentru implementarea comportamentului la nivel de aplicație în mod curat — logging, timing, header-uri personalizate, rate limiting, modul de mentenanță — într-un singur loc în loc să-l repeti pe mai multe views.

Ştiind când să folosești middleware (probleme globale care afectează majoritatea request-urilor) versus decoratori sau logică view-ului (probleme specifice per endpoint) este o decizie arhitecturală cheie.

Middleware-ul este locul în care Django gestionează procesarea request/response care se aplică întregii aplicații, făcând-o o cunoaștere importantă și practic relevantă atât pentru înțelegerea elementelor interne ale framework-ului, cât și pentru construirea de aplicații bine structurate cu separare adecvată a problemelor transversale.