Co je middleware v Django?

Question

Accepted Answer

**Middleware** je rámec hooků, které zpracovávají **každý požadavek a odpověď** globálně a nacházejí se mezi webovým serverem a vašimi views. Každý middleware může kontrolovat/modifikovat požadavky na cestě dovnitř a odpovědi na cestě ven — ideální pro cross-cutting concerns jako autentizace, bezpečnostní hlavičky, sessions a logging.

## Tok požadavku/odpovědi skrze 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 zabudovaný middleware (v 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
```

Velká část funkcí Django jádra je middleware: sessions (`request.session`), autentizace (`request.user`), CSRF ochrana a bezpečnostní hlavičky pocházejí z vestavěného middlewaru. **Pořadí záleží** — některý middleware závisí na tom, že jiné spustí se dříve.

## Psaní vlastního 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
```

Middleware je callable: kód před `self.get_response(request)` se spouští na požadavku, kód po běží na odpovědi. To vám umožňuje jednat jak před, tak po spuštění view.

## Běžné použití 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 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.
```

## Proč to je důležité

Middleware je základem toho, jak Django zpracovává požadavky — jeho pochopení vysvětluje, jak ve skutečnosti funguje řada funkcí jádra frameworku a poskytuje správný mechanismus pro **globální cross-cutting concerns**.

Uvědomění si, že sessions, autentizace (`request.user`), CSRF ochrana a bezpečnostní hlavičky pocházejí z vestavěného middlewaru, demystifikuje zpracování požadavků Django a ukazuje, proč tyto funkce "prostě fungují". Pochopení **vrstveného toku požadavku/odpovědi** (middleware obalující view, zpracovávající požadavky shora dolů a odpovědi zdola nahoru) a že **pořadí záleží** (některý middleware závisí na ostatních, např. autentizace potřebuje session jako první) je důležité pro správné konfigurování Django a ladění problémů.

Schopnost **psát vlastní middleware** je cenná pro implementaci chování v rámci celé aplikace čistě — logging, timing, vlastní hlavičky, rate limiting, režim údržby — na jednom místě místo jeho opakování across views.

Vědomí si, kdy použít middleware (globální concerns ovlivňující většinu požadavků) versus decorators nebo view logiku (per-endpoint concerns) je klíčové architektonické rozhodnutí.

Middleware je místo, kde Django zpracovává požadavky/odpovědi, které se aplikují na celou aplikaci, což z něj činí důležité a prakticky relevantní znalosti jak pro pochopení internálů frameworku, tak pro stavbu dobře strukturovaných aplikací se správným oddělením cross-cutting concerns.