¿Qué es el middleware en Django?

Question

Accepted Answer

**Middleware** es un framework de hooks que procesa **cada solicitud y respuesta** globalmente, situándose entre el servidor web y tus vistas. Cada middleware puede inspeccionar/modificar solicitudes en la entrada y respuestas en la salida — ideal para preocupaciones transversales como autenticación, encabezados de seguridad, sesiones y logging.

## El flujo solicitud/respuesta a través del 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)
```

## Middleware integrado de Django (en 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
```

Mucha de la funcionalidad principal de Django es middleware: sesiones (`request.session`), autenticación (`request.user`), protección CSRF y encabezados de seguridad todos provienen de middleware integrado. **El orden importa** — algunos middleware dependen de que otros se ejecuten primero.

## Escribir middleware personalizado

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

Un middleware es un callable: el código antes de `self.get_response(request)` se ejecuta en la solicitud, el código después se ejecuta en la respuesta. Esto te permite actuar tanto antes como después de la ejecución de la vista.

## Usos comunes del 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 vistas/decoradores

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

## Por qué es importante

El middleware es fundamental para cómo Django procesa solicitudes — entenderlo explica cómo funciona mucha de la funcionalidad principal del framework y proporciona el mecanismo correcto para **preocupaciones globales y transversales**.

Reconocer que sesiones, autenticación (`request.user`), protección CSRF y encabezados de seguridad todos provienen de middleware integrado desmitifica el manejo de solicitudes de Django y muestra por qué estas características "simplemente funcionan". Entender el **flujo de solicitud/respuesta en capas** (middleware envolviendo la vista, procesando solicitudes de arriba hacia abajo y respuestas de abajo hacia arriba) y que **el orden importa** (algunos middleware dependen de otros, como autenticación necesitando sesiones primero) es importante para configurar Django correctamente y depurar problemas.

La capacidad de **escribir middleware personalizado** es valiosa para implementar comportamiento a nivel de aplicación de manera limpia — logging, cronometraje, encabezados personalizados, rate limiting, modo de mantenimiento — en un lugar en lugar de repetirlo a través de vistas.

Saber cuándo usar middleware (preocupaciones globales que afectan la mayoría de solicitudes) versus decoradores o lógica de vistas (preocupaciones por punto final) es una decisión arquitectónica clave.

El middleware es donde Django maneja el procesamiento de solicitud/respuesta que se aplica a toda la aplicación, lo que lo hace un conocimiento importante y prácticamente relevante tanto para entender los internos del framework como para construir aplicaciones bien estructuradas con una separación adecuada de preocupaciones transversales.