Hvad er middleware i Django?

Question

Accepted Answer

**Middleware** er et framework af hooks, der behandler **hver request og response** globalt og sidder mellem webserveren og dine views. Hver middleware kan inspicere/modificere requests på vej ind og responses på vej ud — ideelt til cross-cutting concerns som autentificering, sikkerhedsheaders, sessioner og logging.

## Flowet for request/response gennem 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)
```

## Djangos built-in middleware (i 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
```

Meget af Djangos kernefunktionalitet er middleware: sessioner (`request.session`), autentificering (`request.user`), CSRF-beskyttelse og sikkerhedsheaders kommer alle fra built-in middleware. **Rækkefølgen betyder noget** — nogle middleware afhænger af, at andre kører først.

## Skrive custom 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
```

En middleware er callable: kode før `self.get_response(request)` kører på requestet, kode efter kører på response'et. Dette lader dig handle både før og efter viewets udførelse.

## Almindelige middleware-anvendelser

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

## Hvorfor det betyder noget

Middleware er fundamental for, hvordan Django behandler requests — at forstå det forklarer, hvordan meget af frameworkets kernefunktionalitet faktisk virker og giver den rigtige mekanisme for **globale, cross-cutting concerns**.

At genkende, at sessioner, autentificering (`request.user`), CSRF-beskyttelse og sikkerhedsheaders alle kommer fra built-in middleware, afmystificerer Djangos request-håndtering og viser, hvorfor disse features "blot virker". At forstå **lög-lag request/response-flowet** (middleware der omgiver viewet, behandler requests top-to-bottom og responses bottom-to-top) og at **rækkefølgen betyder noget** (nogle middleware afhænger af andre, som autentificering der har brug for sessioner først) er vigtig for at konfigurere Django korrekt og debugge problemer.

Evnen til at **skrive custom middleware** er værdifuld til at implementere app-bred adfærd på en ren måde — logging, timing, custom headers, rate limiting, vedligeholdelsestilstand — på ét sted i stedet for at gentage det på tværs af views.

At vide, hvornår man skal bruge middleware (globale concerns, der påvirker de fleste requests) versus decorators eller view-logik (per-endpoint concerns) er en vigtig arkitektonisk beslutning.

Middleware er hvor Django håndterer request/response-behandling, der gælder på hele applikationen, hvilket gør det vigtig, praktisk relevant viden både til at forstå frameworkets indre funktioner og til at bygge velstrukturerede applikationer med ordentlig separation af cross-cutting concerns.