Como criar Middlewares customizados no Django

Fala Dev! Na paz?!

Nesse meu primeiro post aqui na Dev.to você vai aprender a criar Middlewares no Django, que são trechos de código para tratamento prévio ou posterior de requisições que chegam e saem do seu sistema Django.

Ficou confuso? Então bora nessa! 😉

O que são Middlewares

Middlewares vivem na Camada View do framework Web Django (que também é composto pela Camada Model e pela Camada Template)

Middlewares são trechos de códigos que podem ser executados antes ou depois do processamento de requisições/respostas pelo Django.

É uma forma que os desenvolvedores, nós, temos para alterar como o Django processa algum dado de entrada ou de saída.

Se você olhar no arquivo settings.py, nós temos a lista MIDDLEWARE com diversos middlewares pré-configurados:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

Por exemplo, o middleware AuthenticationMiddleware é reponsável por adicionar a variável user a todas as requisições.

Dessa forma, você pode, por exemplo, mostrar o usuário logado no seu template:

<li>
    <a href="/alguma/url">Olá, {{ user.email }}</a>
</li>

Vamos ver agora o ciclo de vida de um Middleware dentro do Django.

Ciclo de vida de um Middleware no Django

Um middleware é um método callable (que implementa o método __call__()).

Esse método recebe uma requisição e retorna uma resposta, assim como uma View, podendo ser escrito como função ou como Classe.

Um exemplo de middleware escrito como função é:

def middleware_simples(get_response):
    # Código de inicialização do Middleware
    def middleware(request):
        # Aqui vai o código a ser executado antes 
        # da View e de outros middlewares
        # vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

        response = get_response(request)

        # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        # Aqui vai o código a ser executado 
        # para cada resposta após a View 

        return response

    return middleware

E como Classe:

class MiddlewareSimples:
    def __init__(self, get_response):
        self.get_response = get_response
        # Código de inicialização do Middleware

    def __call__(self, request):
        # Aqui vai o código a ser executado antes 
        # da View e de outros middlewares
        # vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

        response = self.get_response(request)

        # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        # Aqui vai o código a ser executado 
        # para cada resposta após a View         

        return response

Como cada Middleware é executado de maneira encadeada, do topo da configuração MIDDLEWARE (do settings.py) para o fim, a saída de um é a entrada do próximo.

O método get_response() pode ser a própria View, caso ela seja a última configurada no MIDDLEWARE do settings.py, ou o próximo middleware da cadeia.

Utilizando a construção do middleware via Classe, nós temos três métodos importantes:

O método process_view

👉 Assinatura: process_view(request, func, args, kwargs)

Esse método é chamado logo antes do Django executar a View que vai processar a requisição e possui os seguintes parâmetros:

• request é o objeto HttpRequest.
• func é a própria view que o Django está para chamar ao final da cadeia de middlewares.
• args é a lista de parâmetros posicionais que serão passados à view.
• kwargs é o dict contendo os argumentos nomeados (keyword arguments) que serão passados à view.

Esse método deve retornar None ou um objeto HttpResponse:

• Caso retorne None, o Django entenderá que deve continuar a cadeia de Middlewares.
• Caso retorne HttpResponse, o Django entenderá que a resposta está pronta para ser enviada de volta e não vai se preocupar em chamar o resto da cadeia de Middlewares, nem a view que iria processar a requisição.

O método process_exception

👉 Assinatura: process_exception(request, exception)

Esse método é chamada quando uma view lança uma exceção e deve retornar ou None ou HttpResponse. Caso retorne um objeto HttpResponse, o Django irá aplicar o middleware de resposta e o de template, retornando a requisição ao browser.

• request é o objeto HttpRequest
• exception é a exceção propriamente dita lançada pela view (Exception).

O método process_template_response

👉 Assinatura: process_template_response(request, response)

Esse método é chamado logo após a view ter terminado sua execução, caso a resposta tenha uma chamada ao método render() indicando que a reposta possui um template.

Possui os seguintes parâmetros:

• request é um objeto HttpRequest.
• response é o objeto TemplateResponse retornado pela view ou por outro middleware.

Agora vamos criar um middleware um pouco mais complexo para exemplificar o que foi dito aqui!

Criando um Middleware no Django

Vamos supor que queremos um middleware que filtre requisições e só processe aquelas que venham de uma determinada lista de IP's.

O que precisamos fazer é abrir o cabeçalho de todas as requisições que chegam no nosso servidor e verificar se o IP de origem bate com a nossa lista de IP's.

Para isso, colocamos a lógica no método process_view, da seguinte forma:

class FiltraIPMiddleware:    

  def __init__(self, get_response=None):
    self.get_response = get_response

  def __call__(self, request):
    response = self.get_response(request)

    return response

  def process_view(request, func, args, kwargs):
    # Lista de IPs autorizados
    ips_autorizados = ['127.0.0.1']

    # IP do usuário
    ip = request.META.get('REMOTE_ADDR')

    # Verifica se o IP do cliente está na lista de IPs autorizados
    if ip not in ips_autorizados:
      # Se usuário não autorizado > HTTP 403: Não Autorizado
      return HttpResponseForbidden("IP não autorizado")

    # Se for autorizado, não fazemos nada
    return None

Depois disso, precisamos registrar nosso middleware no arquivo de configurações settings.py (na configuração MIDDLEWARE):

MIDDLEWARE = [
  # Middlewares do próprio Django
  'django.middleware.security.SecurityMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  'django.middleware.common.CommonMiddleware',
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware',
  'django.contrib.messages.middleware.MessageMiddleware',
  'django.middleware.clickjacking.XFrameOptionsMiddleware',

  # Nosso Middleware
  'helloworld.middlewares.FiltraIPMiddleware',
]

Agora, podemos testar seu funcionamento alterando a lista ips_autorizados:

• Coloque ips_autorizados = ['127.0.0.1'] e tente acessar alguma URL da nossa aplicação: devemos conseguir acessar normalmente nossa aplicação, pois como estamos executando o servidor localmente, nosso IP será 127.0.0.1 e, portanto, passaremos no teste.
• Coloque ips_autorizados = [] e tente acessar alguma URL da nossa aplicação: deve aparecer a mensagem de "IP não autorizado", pois nosso IP (127.0.0.1) não está autorizado a acessar o servidor.

Conclusão

Nesse primeiro post quis trazer como é simples criar Middlewares no Django.

Você viu como podemos adicionar tratamento prévio ao processamento de requisições e posterior ao processamento de respostas.

Seus casos de uso são bem específicos, contudo é bom saber que temos essa possibilidade!

É isso dev, nos vemos na próxima! 😉