Qu'est-ce que le middleware dans Django ?

Question

Accepted Answer

**Middleware** est un framework de hooks qui traite **chaque requête et réponse** globalement, situé entre le serveur web et vos vues. Chaque middleware peut inspecter/modifier les requêtes à l'entrée et les réponses à la sortie — idéal pour les préoccupations transversales comme l'authentification, les en-têtes de sécurité, les sessions et la journalisation.

## Le flux requête/réponse à travers le 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 intégré de Django (dans 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
```

Beaucoup des fonctionnalités principales de Django sont du middleware : les sessions (`request.session`), l'authentification (`request.user`), la protection CSRF et les en-têtes de sécurité proviennent tous du middleware intégré. **L'ordre est important** — certains middleware dépendent d'autres qui s'exécutent d'abord.

## Écrire du middleware personnalisé

```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 est un callable : le code avant `self.get_response(request)` s'exécute sur la requête, le code après s'exécute sur la réponse. Cela vous permet d'agir avant et après l'exécution de la vue.

## Utilisations courantes du 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 vues/décorateurs

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

## Pourquoi c'est important

Le middleware est fondamental pour la façon dont Django traite les requêtes — le comprendre explique comment une grande partie des fonctionnalités principales du framework fonctionne réellement et fournit le mécanisme approprié pour les **préoccupations transversales et globales**.

Reconnaître que les sessions, l'authentification (`request.user`), la protection CSRF et les en-têtes de sécurité proviennent tous du middleware intégré démystifie la gestion des requêtes de Django et montre pourquoi ces fonctionnalités « fonctionnent simplement ». Comprendre le **flux en couches en oignon requête/réponse** (le middleware enveloppe la vue, traite les requêtes de haut en bas et les réponses de bas en haut) et que **l'ordre est important** (certains middleware dépendent d'autres, comme l'authentification nécessitant les sessions d'abord) est important pour configurer Django correctement et déboguer les problèmes.

La capacité à **écrire du middleware personnalisé** est précieuse pour implémenter un comportement à l'échelle de l'application proprement — journalisation, timing, en-têtes personnalisés, limitation de débit, mode maintenance — en un seul endroit plutôt que de le répéter dans les vues.

Savoir quand utiliser le middleware (préoccupations globales affectant la plupart des requêtes) par rapport aux décorateurs ou à la logique des vues (préoccupations par point de terminaison) est une décision architecturale clé.

Le middleware est l'endroit où Django gère le traitement requête/réponse qui s'applique à toute l'application, ce qui en fait une connaissance importante et pratiquement pertinente pour à la fois comprendre les internals du framework et construire des applications bien structurées avec une séparation appropriée des préoccupations transversales.