Vad är middleware i Django?

Question

Accepted Answer

**Middleware** är ett ramverk med hooks som bearbetar **varje request och response** globalt, och sitter mellan webbservern och dina views. Varje middleware kan inspektera/modifiera requests på vägen in och responses på vägen ut — perfekt för tvärgående krav som autentisering, säkerhetsrubriker, sessioner och loggning.

## Request/response-flödet genom 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 inbyggda 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
```

Mycket av Djangos kärnfunktionalitet är middleware: sessioner (`request.session`), autentisering (`request.user`), CSRF-skydd och säkerhetsrubriker kommer alla från inbyggd middleware. **Ordning spelar roll** — viss middleware är beroende av att andra körs först.

## Skriva egen 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 är en callable: kod före `self.get_response(request)` körs på request, kod efter körs på response. Detta låter dig agera både före och efter view-exekvering.

## Vanliga middleware-användningar

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

## Varför det är viktigt

Middleware är grundläggande för hur Django bearbetar requests — att förstå det förklarar hur mycket av ramverkets kärnfunktionalitet faktiskt fungerar och tillhandahåller rätt mekanism för **globala, tvärgående krav**.

Att inse att sessioner, autentisering (`request.user`), CSRF-skydd och säkerhetsrubriker alla kommer från inbyggd middleware demystifierar Djangos request-hantering och visar varför dessa funktioner "bara fungerar". Att förstå **lök-skikt request/response-flödet** (middleware som omsluter view, bearbetar requests uppifrån och ned och responses nedifrån och upp) och att **ordning spelar roll** (viss middleware är beroende av andra, som autentisering som behöver sessioner först) är viktigt för att konfigurera Django korrekt och felsöka problem.

Förmågan att **skriva egen middleware** är värdefull för att implementera app-bred beteende rent — loggning, timing, anpassade rubriker, hastighetsbegränsning, underhållsläge — på en plats istället för att upprepa det över views.

Att veta när middleware ska användas (globala krav som påverkar de flesta requests) kontra decorators eller view-logik (per-endpoint-krav) är ett viktigt arkitekturbeslut.

Middleware är där Django hanterar request/response-bearbetning som gäller för hela applikationen, vilket gör det till viktigt, praktiskt relevant kunskap för både att förstå ramverkets interna funktionärer och bygga väl strukturerade applikationer med lämplig separation av tvärgående krav.