Was ist Middleware in Django?

Question

Accepted Answer

**Middleware** ist ein Framework von Hooks, die **alle Anfragen und Antworten** global verarbeiten und zwischen dem Webserver und deinen Views sitzen. Jedes Middleware kann Anfragen auf dem Weg hinein und Antworten auf dem Weg heraus inspizieren und ändern — ideal für querschnittliche Belange wie Authentifizierung, Security Headers, Sessions und Logging.

## Der Request/Response-Fluss durch 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 integrierte 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
```

Vieles von Djangos Kernfunktionalität ist Middleware: Sessions (`request.session`), Authentifizierung (`request.user`), CSRF-Schutz und Security Headers stammen alle von integrierter Middleware. **Die Reihenfolge ist wichtig** — einige Middleware hängt davon ab, dass andere zuerst ausgeführt werden.

## Schreiben von 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
```

Ein Middleware ist ein aufrufbares Objekt: Code vor `self.get_response(request)` läuft auf der Anfrage, Code danach läuft auf der Antwort. Das ermöglicht dir, sowohl vor als auch nach der View-Ausführung zu handeln.

## Häufige Middleware-Anwendungen

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

## Warum es wichtig ist

Middleware ist fundamental dafür, wie Django Anfragen verarbeitet — das Verständnis dafür erklärt, wie vieles von den Kernfunktionalitäten des Frameworks tatsächlich funktioniert, und bietet den richtigen Mechanismus für **globale, querschnittliche Belange**.

Zu erkennen, dass Sessions, Authentifizierung (`request.user`), CSRF-Schutz und Security Headers alle von integrierter Middleware stammen, entmystifiziert Djangos Request-Verarbeitung und zeigt, warum diese Funktionen "einfach funktionieren". Das Verständnis des **Zwiebel-Schicht-Request/Response-Flusses** (Middleware umhüllt den View, verarbeitet Anfragen von oben nach unten und Antworten von unten nach oben) und dass **die Reihenfolge wichtig ist** (einige Middleware hängt von anderen ab, wie Authentifizierung, die Sessions zuerst benötigt) ist wichtig für die korrekte Konfiguration von Django und das Debugging von Problemen.

Die Fähigkeit, **Custom Middleware zu schreiben**, ist wertvoll für die Implementierung von App-weitem Verhalten auf saubere Weise — Logging, Timing, benutzerdefinierte Header, Rate Limiting, Wartungsmodus — an einer Stelle, anstatt es über Views zu wiederholen.

Zu wissen, wann man Middleware nutzt (globale Belange, die die meisten Anfragen betreffen) versus Decorators oder View-Logik (Belange pro Endpoint), ist eine wichtige architektonische Entscheidung.

Middleware ist der Ort, wo Django Request/Response-Verarbeitung handhabt, die auf die ganze Anwendung angewendet wird, was es zu wichtigem, praktisch relevantem Wissen macht — sowohl für das Verständnis der Frameworks-Interna als auch für den Aufbau gut strukturierter Anwendungen mit angemessener Trennung querschnittlicher Belange.