Problemas com Cross-Origin Resource Sharing (CORS)

Sejam bem- vindos ao tutorial da Lotus! 😁

 

 

 

O objetivo da Lotus com este blog, é através da própria experiência, auxiliar os alunos que estão cursando ou vão cursar PDS futuramente. A equipe também quer auxiliar os alunos que estão passando pelo desenvolvimento de um projeto, principalmente dentro da área de informática, mesmo que não seja em PDS. Por isso, além dos relatos semanais, dicas e extras, o blog vai contar com alguns tutoriais que podem ser de grande ajuda. 

 

  Um já foi postado e é possível acessá-lo no link:    

 https://lotus-blog-pds.blogspot.com/2023/06/como-fazer-glossario-com-o-latex.html

 

Ao longo do projeto, a equipe encontrou um problema com o CORS, então este post é para ajudar aqueles que encontrarem o mesmo problema.

       Como resolver problema com o CORS        

A comunicação entre o front-end e o back-end é fundamental para o desenvolvimento de aplicações web. No entanto, problemas de Cross-Origin Resource Sharing (CORS) podem surgir para barrar essa comunicação e, por mais que as vezes seja um empecilho técnico, é importante entender que sua aparição é necessária para garantir a segurança na navegação.

Neste post, será discutido o que é o problema de CORS, quando ele aparece e quais medidas que podem ser tomadas para resolvê-lo. Além disso, será compartilhado boas práticas que podem ser úteis para ajudar a lidar com esse desafio em ambiente de desenvolvimento e hospedagem. 

1. O QUE É PROBLEMA DE CORS? 

O CORS é uma política de segurança implementada pelos navegadores para proteger os usuários à ataques de origem cruzada. Em suma, ele impõe restrições à solicitação de recursos de um domínio (origem) diferente do que o recurso pertence. Existe para prevenir justamente a execução não autorizada de scripts em páginas web, assim protegendo os dados e garantindo segurança para o sistema como um todo. 

Origem (em inglês, Origin): é formada pela composição de protocolo e host (e porta caso seja localmente). Por exemplo, você pode desenvolver localmente utilizando http://localhost:80. Onde "http" é o protocolo, "localhost" é o host e "80" é a porta. Qualuqer URL que seja diferente dessa exata combinação é considerada como outra origem, e logo, será necessário realizar a configuração do CORS.  

2. QUANDO ESSE PROBLEMA APARECE? 

O problema de CORS surge quando uma solicitação de recurso é feita a partir de um domínio diferente daquele onde o recurso está localizado. Por exemplo, se uma aplicação front-end hospedada em um domínio "https://seufrontend.com" tentar fazer uma requisição para um servidor back-end hospedado em um domínio "https://api.host.com", o navegador importará a política de CORS e bloqueará a requisição por padrão, resultando na falha de comunicação entre as partes.

3. QUAIS MEDIDAS PODEM SER TOMADAS PARA RESOLVER O PROBLEMA? 

Antes de qualquer ação é essencial ter mais informações do erro obtido. Uma forma interessante de identificar como e onde está ocorrendo o problema de CORS é simular a requisição do recurso que está sendo desenvolvido e utilizar o console do navegador para identificar o erro em detalhes. Isso porque o código Javascript até consegue perceber a ocorrência do erro mas, até por questões de segurança, é somente pelo console que será possível identificar especificamente o que ocorreu.

A partir disso existem soluções para o problema de CORS. Aqui vamos tratar de uma em particular... a que utilizamos para resolver especificamente o erro “No ‘Access-Control-Allow-Origin’ header is presente on the requested resource”. A solução consiste em configurar o back-end da aplicação de forma que permita que as requisições sejam feitas pelo front-end.
Nós criamos uma classe apenas para isso, CorsConfig, e nela deixamos tudo que era necessário (Lembrando que utilizamos Spring boot como tecnologia para o back-end e React JS para o front-end):
 

 

Veja que passamos a URL do nosso front-end como uma origem permitida, e logo após permitimos todos os Headers para o front-end. Também especificamos os métodos HTTP que queremos permitir, nesse caso são todos que pretendemos utilizar.

A ideia é que essa configuração sobrescreva a configuração padrão do CORS, que antes não permitia solicitação de nenhuma origem mas agora permite que o nosso front-end faça as requisições pelos métodos definidos.

Você até poderia dizer para a configuração que a aplicação deve permitir qualquer origem: marcando como “*”, mas como foi dito anteriormente, a não existência do CORS significa um grave problema de segurança, e quando se configura dessa forma, significa que você está liberando acesso para qualquer um... no sentido de que qualquer origem poderia acessar os recursos da sua aplicação.

4. BOAS PRÁTICAS EM AMBIENTE DE DESENVOLVIMENTO DE HOSPEDAGEM

Uma prática que adotamos é não passar diretamente a URL do front-end no código da api:

 

No arquivo de configuração, application.yml, definimos frontend como uma variável de ambiente. Nesse caso, passamos na hospedagem o valor da variável. Fizemos isso não somente para URL do front-end, mas também para todas as credenciais do banco de dados. Tornando o código mais seguro e organizado.
Interessante também é passar não apenas a URL da aplicação em sua forma remota, hospedada, mas também a URL local com a porta utilizada. Dessa forma, fica prático trocar de ambiente de desenvolvimento, o que facilita a execução dos testes concretos.
 

   Caso sinta necessidade de se aprofundar e aprender outras formas de resolver problemas de CORS, recomendamos a leitura da documentação da Mozilla:   

https://developer.mozilla.org/pt-BR/docs/Web/HTTP/CORS

     A equipe espera que o tutorial tenha sido útil. Até o próximo! 😉