Estudo de Caso T2E6: Solução de Problema com IA e MASP - Correção T2E2

INTRODUÇÃO

Este é o episódio 6 da temporada 2 da série “Estudo de Caso”, com foco na correção de um Bug em aplicativo Web, utilizando Inteligência Artificial (IA).

Post onde foi relatado o Bug em App Web: Estudo de Caso T2E2: Solução de Problema com IA e MASP - Aplicativo Web

O objetivo deste Post é mostrar um Prompt para pedir a um Chatbot de IA, uma explicação a respeito de uma correção na configuração onde ocorreu o Bug relatado no Episódio 2 da Temporada 2 da Série Estudo de Caso.

No Episódio 2 o Chatbot de IA Gemini forneceu um Plano de Ação para descobrir a causa do Bug e neste Episódio 2.

Quem corrigiu o bug foi um especialista na tecnologia do app, fazendo ajustes no arquivo de configurações.

O Gemini, neste caso, vai explicar a correção do Bug.

O Prompt terá a estrutura abaixo:

1. Objetivo 
2. Contexto 

Prompt

1 Objetivo

Explique os parâmetros de configuração que foram alterados, para corrigir o bug.

A correção foi realizada pelo especialista na tecnologia onde a App Web está implementada, mas eu preciso entender esses parâmetros de configuração e o funcionamento associado.

2 Contexto

O contexto é de um App Web, com FrontEnd React JS e BackEnd Django, com a configuração abaixo:

2.1 Configuração que havia quando ocorreu o Bug

CORS_ALLOWED_ORIGINS = ["http://0.0.0.0:9501", "http://0.0.0.0:2100",
                               "http://localhost:3000", "http://127.0.0.1:5200",
                               "https://dev-app.votenet.net", "http://dev-app.votenet.net",
                               "http://homologacao.votenet.net", "https://homologacao.votenet.net",
                               "https://dev.votenet.net", "http://dev.votenet.net",
                               "https://app.votenet.net", "http://app.votenet.net",
                               "https://api-dev.votenet.net", "https://api.votenet.net"]
# CORS_ALLOWED_ORIGIN_REGEXES = ["http://0.0.0.0:9501", "http://0.0.0.0:2100",
#                                "http://localhost:3000", "http://127.0.0.1:5200",
#                                "https://dev-app.votenet.net", "http://dev-app.votenet.net",
#                                "http://homologacao.votenet.net", "https://homologacao.votenet.net",
#                                "https://dev.votenet.net", "http://dev.votenet.net",
#                                "https://app.votenet.net", "http://app.votenet.net",
#                                "https://api-dev.votenet.net", "https://api.votenet.net"]
# CORS_ALLOW_ALL_ORIGINS = ["*"]
# CORS_ORIGIN_ALLOW_ALL = True
DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'

2.2 Configuração que ficou após a correção do Bug

DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'

CORS_ALLOW_CREDENTIALS = True
CORS_ALLOWED_ORIGINS = ["http://0.0.0.0:9501", "http://0.0.0.0:2100",
                               "http://localhost:3000", "http://127.0.0.1:5200",
                               "https://dev-app.votenet.net", "http://dev-app.votenet.net",
                               "http://homologacao.votenet.net", "https://homologacao.votenet.net",
                               "https://dev.votenet.net", "http://dev.votenet.net",
                               "https://app.votenet.net", "http://app.votenet.net",
                               "https://api-dev.votenet.net", "https://api.votenet.net"]

CSRF_TRUSTED_ORIGINS = CORS_ALLOWED_ORIGINS

Resposta do Gemini

Link da resposta: https://g.co/gemini/share/34147929350a

Com certeza! A correção do bug foi feita adicionando dois parâmetros essenciais para a comunicação segura e autenticada entre um front-end e um back-end que estão em domínios diferentes: CORS_ALLOW_CREDENTIALS e CSRF_TRUSTED_ORIGINS.

Abaixo explico o que cada um faz e por que a ausência deles provavelmente causou o problema.

---

Resumo da Correção

Foram adicionados dois parâmetros de configuração ao Django para resolver o bug:

1. CORS_ALLOW_CREDENTIALS = True: Permite que o navegador do usuário envie "credenciais" (como cookies de sessão ou tokens de autenticação) em requisições para o back-end.
2. CSRF_TRUSTED_ORIGINS = CORS_ALLOWED_ORIGINS: Informa ao Django que as origens (domínios) do front-end são confiáveis, permitindo que elas realizem operações que alteram dados (como POST, PUT, DELETE).

---

1. CORS_ALLOW_CREDENTIALS = True

Este parâmetro está diretamente ligado ao CORS (Cross-Origin Resource Sharing), que é um mecanismo de segurança do navegador.

• O que são "Credenciais"? No contexto de um navegador, "credenciais" não são apenas login e senha. Elas incluem principalmente:

  • Cookies: Usados para gerenciar sessões de usuário.
  • Tokens de Autenticação: Enviados no cabeçalho da requisição (ex: Authorization: Bearer <token>).
  • Certificados TLS de cliente.

• Por que a alteração foi necessária? Por padrão, mesmo que você liste um domínio em CORS_ALLOWED_ORIGINS, o navegador não envia credenciais em requisições para esse domínio por motivos de segurança.

  O bug provavelmente ocorria quando o seu front-end em React tentava fazer uma chamada à API que necessitava de autenticação (por exemplo, buscar dados do perfil do usuário logado). O navegador, ao ver que a requisição era "cross-origin", bloqueava o envio do cookie de sessão ou do token de autenticação. O back-end Django, ao receber a requisição sem essas credenciais, a tratava como uma chamada anônima e a recusava, gerando um erro.

• Como a correção funciona? Ao definir CORS_ALLOW_CREDENTIALS = True, o servidor Django passa a incluir o cabeçalho Access-Control-Allow-Credentials: true em suas respostas. Isso é um sinal para o navegador do cliente, dizendo: "Pode confiar em mim. Na próxima vez que fizer uma requisição, pode me enviar os cookies e tokens de autenticação que você tem para este domínio."

---

2. CSRF_TRUSTED_ORIGINS = CORS_ALLOWED_ORIGINS

Este parâmetro está relacionado a outra camada de segurança do Django: a proteção contra CSRF (Cross-Site Request Forgery).

• O que é CSRF? É um tipo de ataque onde um site malicioso engana o navegador de um usuário logado para que ele envie uma requisição indesejada para outro site (o seu back-end). O Django possui um sistema de proteção robusto que usa um token (csrfmiddlewaretoken) para validar que as requisições que alteram dados (como POST, PUT, DELETE) vêm de uma fonte confiável (geralmente um formulário renderizado pelo próprio Django).

• Por que a alteração foi necessária? Em uma arquitetura com front-end e back-end separados (React + Django), o front-end está em um domínio diferente. Para métodos "inseguros" (que alteram dados), a proteção CSRF do Django também verifica o cabeçalho Origin da requisição. Se a origem não estiver em uma lista de domínios confiáveis, o Django bloqueia a requisição com um erro 403 Forbidden.

  O bug provavelmente acontecia em qualquer operação que não fosse uma simples leitura de dados (GET). Por exemplo, ao tentar salvar um formulário, criar um novo item ou deletar algo. O React enviava a requisição POST, mas como a origem (https://app.votenet.net, por exemplo) não era explicitamente confiável para o mecanismo CSRF, o Django a rejeitava.

• Como a correção funciona? A linha CSRF_TRUSTED_ORIGINS = CORS_ALLOWED_ORIGINS resolve isso de forma elegante. Ela diz ao Django: "Qualquer domínio que já foi autorizado para fazer requisições (pela configuração do CORS) também é considerado confiável para enviar requisições que alteram dados."

  Isso reutiliza a lista já existente de origens permitidas, garantindo que apenas os seus front-ends autorizados possam executar ações de escrita na API.

Conclusão

A correção foi executada pelo desenvolvedor e os detalhes técnicos explicados pelo Gemini.

Demais Episódios da Temporada:

• Série Estudo de Caso:
• Temporada T2 Solução de Problema com IA e MASP:
• Episódio E1 Serviço de infraestrutura na nuvem
• Episódio E2 Aplicativo Web
• Episódio E3 Instalação de Aplicativo
• Episódio E4 Aplicativo Web
• Episódio E5 Correção T2E4