Mikä on middleware Djangossa?

Question

IT Interview Practice · Accepted Answer

**Middleware** on kehys, joka käsittelee **jokaista pyyntöä ja vastausta** globaalisti, istuen web-palvelimen ja näkymien välillä. Jokainen middleware voi tarkastaa/muokata pyyntöjä sisääntulon aikana ja vastauksia ulostulolla — ihanteellinen yleiset huolenaiheet kuten autentikointi, suojauspäivitykset, istunnot ja lokitus.

## Pyynnön/vastauksen kulku middlewaren läpi

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

## Djangon sisäänrakennettu middleware (settings.py:ssä)

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

Suuri osa Djangon ydinominaisuuksista on middleware: istunnot (`request.session`), autentikointi (`request.user`), CSRF-suoja ja suojauspäivitykset tulevat kaikki sisäänrakennetusta middlewaresta. **Järjestys on tärkeä** — osa middlewaresta riippuu siitä, että muut middleware suoritetaan ensin.

## Räätälöidyn middleware kirjoittaminen

```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 on kutsuttava: koodi ennen `self.get_response(request)` suoritetaan pyynnölle, koodi sen jälkeen suoritetaan vastaukselle. Tämä sallii sinun toimia sekä ennen että jälkeen näkymän suorittamisen.

## Yleisiä middleware-käyttötapauksia

```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 näkymät/dekoraattorit

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

## Miksi se on tärkeää

Middleware on perustavanlaatuinen sille, kuinka Django käsittelee pyyntöjä — sen ymmärtäminen selittää, kuinka suuri osa kehyksen ydinominaisuuksista todella toimii, ja tarjoaa oikean mekanismin **globaaleille, yleisille huolille**.

Tunnistaminen, että istunnot, autentikointi (`request.user`), CSRF-suoja ja suojauspäivitykset tulevat kaikki sisäänrakennetusta middlewaresta, tekee Djangon pyynnön käsittelystä selkeämpää ja osoittaa, miksi nämä ominaisuudet "vain toimivat". **Sipuli-kerros pyynnön/vastauksen kulun** ymmärtäminen (middleware ympäröi näkymää, käsittelee pyyntöjä ylhäältä alaspäin ja vastauksia alhaalta ylöspäin) ja että **järjestys on tärkeä** (osa middlewaresta riippuu muista, kuten autentikoinnin tarpeesta istunnoille ensin) on tärkeää Djangon konfigurointiin ja ongelmanratkaisuun.

**Räätälöidyn middleware kirjoittamisen** kyky on arvokasta sovelluksen laajuisen käyttäytymisen toteuttamiseen puhtaasti — lokitus, ajoitukset, räätälöidyt otsikot, nopeuden rajoitus, ylläpidon tila — yhdessä paikassa sen sijaan, että toistat sitä näkymien yli.

Tietäminen, milloin käyttää middlewarea (globaalit huolet, jotka vaikuttavat useimpiin pyyntöihin) verrattuna dekoraattoreihin tai näkymän logiikkaan (yksittäisten päätepisteissä olevat huolet) on keskeinen arkkitehtuurin päätös.

Middleware on paikka, jossa Django käsittelee pyynnön/vastauksen käsittelyä, joka koskee koko sovellusta, mikä tekee siitä tärkeää, käytännöllistä tietoa sekä kehyksen sisäosien ymmärtämiseksi että hyvin strukturoitujen sovellusten rakentamiseksi oikealla yleisinä huolenaiheina.

Pyynnön/vastauksen kulku middlewaren läpi

Djangon sisäänrakennettu middleware (settings.py:ssä)

Räätälöidyn middleware kirjoittaminen

Yleisiä middleware-käyttötapauksia

Middleware vs näkymät/dekoraattorit

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset