Wat is middleware in Django?

Question

Accepted Answer

**Middleware** is een raamwerk van hooks die **elk request en response** wereldwijd verwerken, gepositioneerd tussen de webserver en je views. Elke middleware kan requests onderweg inspecteren/wijzigen en responses onderweg aanpassen — ideaal voor cross-cutting concerns zoals authenticatie, beveiligingsheaders, sessions en logging.

## De request/response flow door 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)
```

## Django's ingebouwde middleware (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
```

Much of Django's kernfunctionaliteit is middleware: sessions (`request.session`), authenticatie (`request.user`), CSRF-bescherming en beveiligingsheaders komen allemaal uit ingebouwde middleware. **Volgorde is belangrijk** — sommige middleware is afhankelijk van anderen die eerst worden uitgevoerd.

## Aangepaste middleware schrijven

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

Een middleware is een callable: code voor `self.get_response(request)` wordt uitgevoerd op het request, code erna op het response. Dit laat je zowel voor als na viewuitvoering handelen.

## Gangbare middleware-toepassingen

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

## Waarom het belangrijk is

Middleware is fundamenteel voor hoe Django requests verwerkt — inzicht hierin verklaart hoe veel van de kernfunctionaliteit van het raamwerk daadwerkelijk werkt en biedt het juiste mechanisme voor **globale, cross-cutting concerns**.

Het erkennen dat sessions, authenticatie (`request.user`), CSRF-bescherming en beveiligingsheaders allemaal uit ingebouwde middleware komen, ontraadselt Djangos requestverwerking en laat zien waarom deze features "gewoon werken". Het begrijpen van de **ui-laag request/response flow** (middleware omgeeft de view, verwerkt requests van boven naar beneden en responses van beneden naar boven) en dat **volgorde belangrijk is** (sommige middleware is afhankelijk van anderen, zoals authenticatie die sessions eerst nodig heeft) is belangrijk voor het correct configureren van Django en het debuggen van problemen.

Het vermogen om **aangepaste middleware te schrijven** is waardevol voor het schoon implementeren van app-breed gedrag — logging, timing, aangepaste headers, rate limiting, onderhoudsmodus — op één plek in plaats van het herhalen in views.

Weten wanneer je middleware moet gebruiken (globale concerns die de meeste requests beïnvloeden) versus decorators of viewlogica (per-endpoint concerns) is een belangrijke architecturale beslissing.

Middleware is waar Django request/response verwerking afhandelt die van toepassing is op de hele applicatie, wat het belangrijk en praktisch relevant kennis maakt voor zowel het begrijpen van de interne werking van het raamwerk als het bouwen van goed gestructureerde applicaties met correct scheidingskader voor cross-cutting concerns.