Kaj je middleware v Django-ju?

Question

Accepted Answer

**Middleware** je ogrodje sistemskih kljuk, ki obdelajo **vsak zahtevek in odgovor** globalno, nahajajući se med spletnim strežnikom in vašimi pogledi. Vsak middleware lahko pregleda/spremeni zahtevke na poti vhoda in odgovore na poti izhoda — idealen za prečne probleme kot sta avtentifikacija in varnostne glave, seje in beleženje.

## Tok zahtevka/odgovora skozi 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-jevo vgrajeno 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
```

Velik del Django-jeve temeljne funkcionalnosti je middleware: seje (`request.session`), avtentifikacija (`request.user`), CSRF zaščita in varnostne glave vse izhajajo iz vgrajenega middleware. **Vrstni red je pomemben** — nekateri middleware je odvisni od tega, da se drugi najprej zagnanejo.

## Pisanje prilagojenega 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 naklicljiv: koda pred `self.get_response(request)` se izvede na zahtevku, koda po tem se izvede na odgovoru. To vam omogoča, da delujete pred in po izvajanju pogleda.

## Splošne rabe 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 pogledi/dekoratorji

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

## Zakaj je to pomembno

Middleware je temeljni za to, kako Django obdeluje zahtevke — razumevanje tega pojasni, kako dejansko deluje večina temeljne funkcionalnosti ogrodja in zagotavlja pravi mehanizem za **globalne, prečne probleme**.

Ugotovitev, da seje, avtentifikacija (`request.user`), CSRF zaščita in varnostne glave vse izvirajo iz vgrajenega middleware, razjasnijo Django-jevo obdelavo zahtevkov in pokažejo, zakaj te lastnosti »preprosto delujejo«. Razumevanje **toka slojev čebule zahtevka/odgovora** (middleware obda pogled, obdeluje zahtevke od zgoraj navzdol in odgovore od spodaj navzgor) in da je **vrstni red pomemben** (nekateri middleware so odvisni od drugih, kot je avtentifikacija, ki potrebuje seje prva) je pomembna za pravilno konfiguracijo Django-ja in odpravljanje težav.

Možnost **pisanja prilagojenega middleware** je dragocena za izvajanje vedenja v celotni aplikaciji čisto — beleženje, timing, lastne glave, omejevanje hitrosti, način vzdrževanja — na enem mestu, namesto da bi ga ponavljali v različnih pogledih.

Znanje, kdaj uporabiti middleware (globalni problemi, ki vplivajo na večino zahtevkov) v primerjavi z dekoratorji ali logiko pogleda (problemi na specifičnih končnih točkah) je ključna odločitev v arhitekturi.

Middleware je tam, kjer Django obdeluje obdelavo zahtevka/odgovora, ki se nanaša na celotno aplikacijo, zato je praktično relevantno znanje za razumevanje notranjosti ogrodja in gradnjo dobro strukturiranih aplikacij s pravilno ločitvijo prečnih problemov.