Django viene con algunos middleware incorporados para lidiar con problemas comunes, los cuales discutiremos en las secciones que siguen.
15.4.1. Middleware de soporte para autenticación
Clase middleware: django.contrib.auth.middleware.AuthenticationMiddleware
.
Este middleware permite el soporte para autenticación. Agrega el atributo
request.user
, que representa el usuario actual registrado, a todo objeto
HttpRequest
que se recibe.
Mira el Capítulo 12 para los detalles completos.
15.4.2. Middleware "Common"
Clase middleware: django.middleware.common.CommonMiddleware
.
Este middleware agrega algunas conveniencias para los perfeccionistas:
1. Prohíbe el acceso a los agentes de usuario especificados en la
configuración DISALLOWED_USER_AGENTS
:
Si se especifica, esta configuración debería ser una lista de objetos de expresiones regulares compiladas que se comparan con el encabezado user-agent de cada petición que se recibe. Aquí esta un pequeño ejemplo de un archivo de configuración:
import re
DISALLOWED_USER_AGENTS = (
re.compile(r'^OmniExplorer_Bot'),
re.compile(r'^Googlebot')
)
Nota el import re
, ya que DISALLOWED_USER_AGENTS
requiere que sus
valores sean expresiones regulares compiladas (es decir, el resultado de
re.compile()
). El archivo de configuración es un archivo común de
Python, por lo tanto es perfectamente adecuado incluir sentencias
import
en él.
2. Realiza re-escritura de URL basado en las configuraciones APPEND_SLASH
y PREPEND_WWW
Si APPEND_SLASH
es igual a True
, las URLs que no poseen una barra al final
serán redirigidas a la misma URL con una barra al final, a menos que el último
componente en el path contenga un punto. De esta manera foo.com/bar
es
redirigido a foo.com/bar/
, pero foo.com/bar/file.txt
es pasado a través
sin cambios.
Si PREPEND_WWW
es igual a True
, las URLs que no poseen el prefijo
"www." serán redirigidas a la misma URL con el prefijo "www.".
Ambas opciones tienen por objeto normalizar URLs. La filosofía es que cada
URL debería existir en un — y sólo un — lugar. Técnicamente la URL
example.com/bar
es distinta de example.com/bar/
, la cual a su vez
es distinta de www.example.com/bar/
. Un motor de búsqueda indexador
trataría de forma separada estas URLs, lo cual es perjudicial para la
valoración de tu sitio en el motor de búsqueda, por lo tanto es una buena
práctica normalizar las URLs.
3. Maneja ETags basado en la configuración USE_ETAGS
:
ETags son una optimización a nivel HTTP para almacenar condicionalmente las
páginas en la caché. Si USE_ETAGS
es igual a True
, Django calculará una
ETag para cada petición mediante la generación de un hash MD5 del contenido de
la página, y se hará cargo de enviar respuestas Not Modified
, si es
apropiado.
Nota también que existe un middleware de GET
condicional, que veremos
en breve, el cual maneja ETags y hace algo más.
15.4.3. Middleware de compresión
Clase middleware: django.middleware.gzip.GZipMiddleware
.
Este middleware comprime automáticamente el contenido para aquellos navegadores que comprenden la compresión gzip (todos los navegadores modernos). Esto puede reducir mucho la cantidad de ancho de banda que consume un servidor Web. La desventaja es que esto toma un poco de tiempo de procesamiento para comprimir las páginas.
Nosotros por lo general preferimos velocidad sobre ancho de banda, pero si tu prefieres lo contrario, solo habilita este middleware.
15.4.4. Middleware de GET condicional
Clase middleware: django.middleware.http.ConditionalGetMiddleware
.
Este middleware provee soporte para operaciones GET
condicionales. Si la
respuesta contiene un encabezado Last-Modified
o ETag
, y la petición
contiene If-None-Match
o If-Modified-Since
, la respuesta es reemplazada
por una respuesta 304 ("Not modified"). El soporte para ETag
depende de la
configuración USE_ETAGS
y espera que el encabezado ETag
de la respuesta
ya este previamente fijado. Como se señaló anteriormente, el encabezado ETag
es fijado por el middleware Common.
También elimina el contenido de cualquier respuesta a una petición HEAD
y
fija los encabezados de respuesta Date
y Content-Length
para todas las
peticiones.
15.4.5. Soporte para uso de proxy inverso (Middleware X-Forwarded-For)
Clase middleware: django.middleware.http.SetRemoteAddrFromForwardedFor
.
Este es el ejemplo que examinamos en la sección anterior "Qué es middleware".
Este establece el valor de request.META['REMOTE_ADDR']
basándose en el
valor de request.META['HTTP_X_FORWARDED_FOR']
, si este último esta fijado.
Esto es útil si estas parado detrás de un proxy inverso que provoca que cada
petición REMOTE_ADDR
sea fijada a 127.0.0.1
.
Advertencia Este middleware no hace validar HTTP_X_FORWARDED_FOR
.
Si no estas detrás de un proxy inverso que establece
HTTP_X_FORWARDED_FOR
automáticamente, no uses este middleware.
Cualquiera puede inventar el valor de HTTP_X_FORWARDED_FOR
, y ya que
este establece REMOTE_ADDR
basándose en HTTP_X_FORWARDED_FOR
,
significa que cualquiera puede falsear su dirección IP.
Solo usa este middleware cuando confíes absolutamente en el valor de
HTTP_X_FORWARDED_FOR
.
15.4.6. Middleware de soporte para sesiones
Clase middleware: django.contrib.sessions.middleware.SessionMiddleware
.
Este middleware habilita el soporte para sesiones. Mira el Capítulo 12 para más detalles.
15.4.7. Middleware de cache de todo el sitio
Clase middleware: django.middleware.cache.CacheMiddleware
.
Este middleware almacena en la cache cada página impulsada por Django. Este se analizó en detalle en el Capítulo 13.
15.4.8. Middleware de transacción
Clase middleware: django.middleware.transaction.TransactionMiddleware
.
Este middleware asocia un COMMIT
o ROLLBACK
de la base de datos con una
fase de petición/respuesta. Si una vista de función se ejecuta con éxito, se
emite un COMMIT
. Si la vista provoca una excepción, se emite un
ROLLBACK
.
El orden de este middleware en la pila es importante. Los módulos middleware que se ejecutan fuera de este, se ejecutan con commit-on-save — el comportamiento por omisión de Django. Los módulos middleware que se ejecutan dentro de este (próximos al final de la pila) estarán bajo el mismo control de transacción que las vistas de función.
Mira el Apéndice C para obtener más información sobre las transacciones de base de datos.
15.4.9. Middleware "X-View"
Clase middleware: django.middleware.doc.XViewMiddleware
.
Este middleware envía cabeceras HTTP X-View
personalizadas a peticiones HEAD
que provienen de direcciones IP definidas en la configuración INTERNAL_IPS
.
Esto es usado por el sistema automático de documentación de Django.