Referência dos middlewares embutidos¶
Este documento detalha todos os componentes middleware que acompanham o Django. Para informações de como usá-los e de como escrever o seu próprio middleware, veja o guia de uso de middleware.
Middlewares disponíveis¶
Middleware de cache¶
-
class
django.middleware.cache.
UpdateCacheMiddleware
¶
-
class
django.middleware.cache.
FetchFromCacheMiddleware
¶
Habilita o cache em todo o site. Se este estiver habilitado, cada página
construída pelo Django será cacheada durante o tempo definido em
CACHE_MIDDLEWARE_SECONDS
. Veja a documentação do cache.
Middleware “Common”¶
-
class
django.middleware.common.
CommonMiddleware
¶
Adiciona algumas conveniências para perfeccionistas:
Proíbe o acesso de “user agents” especificados em
DISALLOWED_USER_AGENTS
, o qual deve ser uma lista de strings.Executa uma reescrita de URL baseada nas configurações
APPEND_SLASH
ePREPEND_WWW
.Se o
APPEND_SLASH
forTrue
e a URL inicial não terminar com uma barra, e ela não for encontrada no URLconf, então uma nova URL é formada, adicionando uma barra no final. Se esta nova URL é encontrada no URLconf, o Django redireciona a requisição para esta nova URL. Por outro lado, a URL inicial é processada habitualmente.Por exemplo,
foo.com/bar
será redirecionado parafoo.com/bar/
se você não tiver um padrão de URL válido parafoo.com/bar
mas tem um padrão válido parafoo.com/bar/
.O comportamento doAPPEND_SLASH
mudou ligeiramente nesta versão. Ele não é utilizado para verificar se o padrão confere na URLconf.Se o
PREPEND_WWW
éTrue
, as URLs que faltam um “www.” na frente serão redirecionadas para a mesma URL com o “www.” na frente.Estes dois tipos de opções são destinadas a normalizar URLs. A filosofia é que cada URL deve existir em um, e somente um, lugar. Tecnicamente uma URL
foo.com/bar
é diferente defoo.com/bar/
– um indexador de motor de busca tratará elas como URLs separadas – então esta é a melhor prática para normalizar URLs.Manipula ETags baseado na configuração
USE_ETAGS
. Se oUSE_ETAGS
é definido comoTrue
, o Django calculará um ETag para cada requisição usando um hash MD5 do conteúdo da página, e irá se responsabilizar por enviar repostasNot Modified
(não modificado), se apropriado.
Middleware view metadata¶
-
class
django.middleware.doc.
XViewMiddleware
¶
Envia cabeçalhos HTTP X-View
personalizados para requisições HEAD oriundas
de endereços IP definidos na configuração INTERNAL_IPS
. Isso é
utilizado pelo sistema de documentação automática do Django.
Middleware GZIP¶
-
class
django.middleware.gzip.
GZipMiddleware
¶
Comprime conteúdos para navegadores que entendem compressão gzip (todos os navegadores modernos).
É sugerido colocá-lo em primeiro na lista de middlewares, desta forma a
compressão do conteúdo de resposta será a última coisa a ser feita. Não serão
comprimidos conteúdos menores que 200 bytes, quando o código de resposta for
diferente de 200, quando arquivos JavaScript (para compatibilidade com IE), ou
quando as respostas possuem o cabeçalho Content-Encoding
já especificado.
Middleware GET condicional¶
-
class
django.middleware.http.
ConditionalGetMiddleware
¶
Manipula operações condicionais do GET. Se a resposta tem um cabeçalho ETag
ou Last-Modified
, e a requisição possui If-None-Match
ou
If-Modified-Since
, a resposta é substituída por um
HttpNotModified`
.
Também define os cabeçalhos de resposta Date
e Content-Length
.
Middleware para proxy reverso¶
-
class
django.middleware.http.
SetRemoteAddrFromForwardedFor
¶
Define o request.META['REMOTE_ADDR']
baseado no
request.META['HTTP_X_FORWARDED_FOR']
, se o último estiver definido. Isso é
útil se você estiver por trás de um proxy reverso que faz com que cada
REMOTE_ADDR
seja definido como 127.0.0.1
.
Nota importante: Isso NÃO valida o HTTP_X_FORWARDED_FOR
. Se você não
está atrás de um proxy reverso que define o HTTP_X_FORWARDED_FOR
automaticamente, não utilize este middleware. Ninguém pode burlar o valor do
HTTP_X_FORWARDED_FOR
, e por causa disso defina REMOTE_ADDR
baseado no
HTTP_X_FORWARDED_FOR
, o que significa que ninguém pode “falsificar” seus
endereços de IP. Somente use isto quando você confia absolutamente no valor do
HTTP_X_FORWARDED_FOR
.
Middleware Locale¶
-
class
django.middleware.locale.
LocaleMiddleware
¶
Habilita a seleção de idioma baseado em dados vindos da requisição. Ele personaliza o conteúdo para cada usuário. Veja a documentação de internacionalização.
Middleware Session¶
-
class
django.contrib.sessions.middleware.
SessionMiddleware
¶
Habilita o suporte a sessões. Veja a documentação de sessões.
Middleware Authentication¶
-
class
django.contrib.auth.middleware.
AuthenticationMiddleware
¶
Adiciona o atributo user
, representando o usuário atualmente logado, para
todo objeto HttpRequest
que chega. Veja Autenticação em requisições
Web.
Middleware de proteção CSRF¶
-
class
django.contrib.csrf.middleware.
CsrfMiddleware
¶
Adiciona proteção contra Cross Site Request Forgeries adicionando campos invisíveis de formulários aos formulários POST e checando suas requisições pelos valores corretos. Veja a documentação da proteção de Cross Site Request Forgeries.
Middleware Transaction¶
-
class
django.middleware.transaction.
TransactionMiddleware
¶
Vincula commit e rollback às fases request/response. Se uma função view é executada com sucesso, um commit é feito. Se ela falhar com uma exceção, um rollback é realizado.
A ordem deste middleware na pilha é importante: módulos middleware rodando fora dele rodam com commit-on-save - o comportamento padrão do Django. Módulos middleware rodando dentro dele (vêm depois na pilha) estarão abaixo do mesmo controle de transações como nas funções view.