Co to jest middleware w Django?

Question

Accepted Answer

**Middleware** to framework hooks, które przetwarzają **każde żądanie i odpowiedź** globalnie, usytuowany między serwerem sieciowym a widokami. Każdy middleware może inspektować/modyfikować żądania na wejściu i odpowiedzi na wyjściu — idealny do cross-cutting concerns takich jak uwierzytelnianie, nagłówki bezpieczeństwa, sesje i logowanie.

## Przepływ żądania/odpowiedzi przez 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)
```

## Wbudowany middleware Django (w 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
```

Wiele funkcjonalności rdzenia Django to middleware: sesje (`request.session`), uwierzytelnianie (`request.user`), ochrona CSRF i nagłówki bezpieczeństwa — wszystko pochodzi z wbudowanego middleware. **Kolejność ma znaczenie** — niektóre middleware zależy od tego, że inne uruchamiają się pierwsze.

## Pisanie niestandardowego 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 to callable: kod przed `self.get_response(request)` uruchamia się na żądaniu, kod po uruchamia się na odpowiedzi. To pozwala działać zarówno przed jak i po wykonaniu widoku.

## Popularne zastosowania 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 widoki/dekoratory

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

## Dlaczego to ważne

Middleware jest fundamentalny dla tego, jak Django przetwarza żądania — zrozumienie go wyjaśnia, jak wiele funkcjonalności rdzenia framework'u faktycznie działa i dostarcza właściwy mechanizm dla **globalnych, cross-cutting concerns**.

Zauważenie, że sesje, uwierzytelnianie (`request.user`), ochrona CSRF i nagłówki bezpieczeństwa pochodzą z wbudowanego middleware demistyfikuje obsługę żądań Django i pokazuje, dlaczego te funkcje "po prostu działają". Zrozumienie **przepływu request/response warstwami cebuli** (middleware otaczający widok, przetwarzający żądania od góry do dołu i odpowiedzi od dołu do góry) i że **kolejność ma znaczenie** (niektóre middleware zależy od innych, jak uwierzytelnianie wymagające sesji najpierw) jest ważne dla poprawnego skonfigurowania Django i debugowania problemów.

Możliwość **pisania niestandardowego middleware** jest cenna do implementacji zachowania w skali aplikacji w czysty sposób — logowanie, timing, niestandardowe nagłówki, rate limiting, tryb konserwacji — w jednym miejscu zamiast powtarzania tego w widokach.

Wiedzenie, kiedy użyć middleware (globalne concerns dotyczące większości żądań) versus dekoratory lub logika widoku (per-endpoint concerns) to kluczowa decyzja architektoniczna.

Middleware to miejsce, gdzie Django obsługuje request/response processing, który stosuje się do całej aplikacji, czyniąc to ważną, praktycznie istotną wiedzą zarówno do zrozumienia wnętrza framework'u jak i budowania dobrze skonstruowanych aplikacji z właściwym rozdzieleniem cross-cutting concerns.