Che cos'è il middleware in Django?

Question

Accepted Answer

**Middleware** è un framework di hook che elabora **ogni request e response** globalmente, posizionandosi tra il web server e le tue views. Ogni middleware può ispezionare/modificare i request in entrata e i response in uscita — ideale per cross-cutting concerns come autenticazione, security header, sessioni e logging.

## Il flusso request/response attraverso il 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)
```

## Il middleware built-in di Django (in 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
```

Molta della funzionalità core di Django è middleware: sessioni (`request.session`), autenticazione (`request.user`), protezione CSRF e security header provengono tutti da middleware built-in. **L'ordine conta** — alcuni middleware dipendono da altri che vengono eseguiti per primi.

## Scrivere middleware personalizzato

```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 è un callable: il codice prima di `self.get_response(request)` viene eseguito sul request, il codice dopo viene eseguito sul response. Questo ti permette di agire sia prima che dopo l'esecuzione della view.

## Usi comuni del 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/decorators

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

## Perché è importante

Il middleware è fondamentale per come Django elabora i request — comprenderlo spiega come funziona effettivamente gran parte della funzionalità core del framework e fornisce il meccanismo giusto per **cross-cutting concerns globali**.

Riconoscere che sessioni, autenticazione (`request.user`), protezione CSRF e security header provengono tutti da middleware built-in demistifica la gestione dei request di Django e mostra perché queste funzionalità "funzionano semplicemente". Comprendere il **flusso a strati di cipolla request/response** (middleware che avvolge la view, elaborando i request dall'alto verso il basso e i response dal basso verso l'alto) e che **l'ordine conta** (alcuni middleware dipendono da altri, come l'autenticazione che ha bisogno delle sessioni prima) è importante per configurare Django correttamente e per il debug dei problemi.

La capacità di **scrivere middleware personalizzato** è preziosa per implementare il comportamento a livello di app in modo pulito — logging, timing, custom header, rate limiting, maintenance mode — in un unico posto piuttosto che ripeterlo attraverso le views.

Sapere quando usare il middleware (cross-cutting concerns globali che interessano la maggior parte dei request) versus decorators o logica nella view (cross-cutting concerns per-endpoint) è una decisione architettonica fondamentale.

Il middleware è dove Django gestisce l'elaborazione request/response che si applica all'intera applicazione, rendendolo una conoscenza importante e praticamente rilevante sia per comprendere gli interni del framework che per costruire applicazioni ben strutturate con una corretta separazione dei cross-cutting concerns.