Exemplo Completo de Requisições Ajax Cross-Domain: Interação Frontend-Backend

Este exemplo detalha como implementar requisições cross-domain utilizando a tecnologia Ajax, abrangendo as implementações tanto no frontend com JavaScript (utilizando$.ajax do jQuery) quanto no backend com Java Servlet. O foco no frontend é a configuração de requisições Ajax para habilitar comunicação cross-domain, enquanto o backend gerencia requisições cross-domain através da configuração de cabeçalhos de resposta HTTP, garantindo a transmissão segura e eficiente de dados entre domínios distintos. Ao estudar este exemplo, os desenvolvedores estarão aptos a resolver problemas de cross-domain em projetos reais e a compreender o mecanismo CORS.

  1. Introdução ao Ajax e Criação Dinâmica de Páginas Web

1.1 Breve Introdução ao Ajax

Ajax (Asynchronous JavaScript and XML) é uma técnica que permite atualizar partes de uma página web sem a necessidade de recarregar o documento inteiro. Através de uma troca mínima de dados com o servidor em segundo plano, o Ajax possibilita atualizações assíncronas da página, melhorando significativamente a experiência do usuário.

1.2 O Papel do Ajax na Criação de Páginas Dinâmicas

O Ajax desempenha um papel crucial na criação de páginas dinâmicas. Ele permite que a página solicite recursos do servidor com base nas interações do usuário e exiba os dados retornados dinamicamente, sem recarregar toda a página. Isso resulta em uma navegação mais fluida e uma experiência de usuário mais amigável.

1.3 Princípio de Funcionamento do Ajax

O núcleo do Ajax é o objeto JavaScript XMLHttpRequest (XHR), uma API que permite que navegadores com JavaScript habilitado comuniquem-se com servidores. Ao criar um objeto XHR, o navegador pode enviar requisições ao servidor e receber dados sem a necessidade de recarregar a página, atualizando dinamicamente o conteúdo da página através de JavaScript.

  1. Método $.ajax() do jQuery e Configuração de Requisições Cross-Domain

2.1 Aplicação Básica do Método $.ajax()

2.1.1 Análise dos Parâmetros do Método $.ajax()

O método $.ajax() do jQuery permite criar requisições AJAX com diversas opções de personalização. Abaixo estão os parâmetros mais comuns:

  • url: (Obrigatório) O endereço do servider para onde a requisição será enviada.
  • type: O método HTTP a ser utilizado (GET, POST, PUT, DELETE, etc.), com GET sendo o padrão.
  • timeout: Tempo limite da requisição em milissegundos.
  • async: Booleano que indica se a requisição será assíncrona (true por padrão).
  • contentType: O tipo de conteúdo enviado ao servidor.
  • data: Os dados a serem enviados ao servidor.
  • dataType: O tipo de dado esperado na resposta do servidor.
  • headers: Um objeto contendo cabeçalhos HTTP customizados.
  • processData: Booleano que indica se os dados devem ser transformados em uma string de consulta (true por padrão).
  • xhrFields: Um objeto para configurar propriedades do objeto XMLHttpRequest.
  • success(data, textStatus, jqXHR): Função de callback executada em caso de sucesso.
  • error(jqXHR, textStatus, errorThrown): Função de callback executada em caso de falha.

Os parâmetros são passados como um objeto literal:


$.ajax({
   url: "seu-endpoint", // Endereço do servidor
   type: "GET", // Método da requisição
   async: true, // Requisição assíncrona
   data: { chave: "valor" }, // Dados a serem enviados
   dataType: "json", // Tipo de dado esperado na resposta
   success: function(response) {
       console.log("Dados recebidos:", response);
   },
   error: function(jqXHR, textStatus) {
       console.error("Falha na requisição: " + textStatus);
   }
});

Este exemplo configura uma requisição GET com dados e espera uma resposta em formato JSON. Em caso de sucesso, os dados são logados no console; em caso de falha, a mensagem de erro é exibida.

2.1.2 Exemplo de Uso do Método $.ajax()

Abaixo, um exemplo de carregamento assíncrono de dados:


<div id="content"></div>
   


$(document).ready(function() {
   $.ajax({
       url: "data.php", // Arquivo PHP no servidor
       type: "GET",
       dataType: "html",
       success: function(data) {
           // Carrega o conteúdo retornado no div com id "content"
           $("#content").html(data);
       },
       error: function(jqXHR, textStatus, errorThrown) {
           console.error("Erro ao carregar data.php: " + textStatus);
       }
   });
});

Após o carregamento da página, uma requisição AJAX busca o conteúdo do arquivo data.php e o insere no elemento div com id="content". Erros são logados no console.

2.2 Configuração de Requisições Ajax Cross-Domain com $.ajax()

2.2.1 Princípio e Implementação de JSONP

JSONP (JSON with Padding) é uma técnica para superar as restrições de cross-domain. Ela funciona criando uma tag <script> cujo atributo src aponta para a URL da requisição. O servidor, então, envolve os dados JSON em uma chamada de função de callback especificada na URL.

As tags <script> não estão sujeitas à mesma política de origem (Same-Origin Policy), permitindo o carregamento de scripts de qualquer domínio.


function handleJsonResponse(response) {
   console.log("Dados JSONP recebidos:", response);
}

var scriptElement = document.createElement('script');
scriptElement.src = "https://outrodominio.com/dados?callback=handleJsonResponse";
document.body.appendChild(scriptElement);

Neste exemplo, a função global handleJsonResponse é usada como callback. Um novo elemento <script> é criado, com o src apontando para o recurso cross-domain e incluindo o parâmetro callback para especificar a função a ser chamada com os dados.

2.2.2 Considerações sobre Requisições Cross-Domain com $.ajax()

  • Suporte a CORS: Se o servidor de destino suportar CORS (Cross-Origin Resource Sharing), requisições $.ajax() podem ser usadas diretamente, desde que o servidor configure os cabeçalhos de resposta corretamente.
  • Restrições de Segurança: Navegadores modernos limitam o uso de JSONP por razões de segurança, especialmente para requisições com determinados Content-Type.
  • Criação Dinâmica de Scripts: JSONP envolve a criação dinâmica de elementos <script>, o que exige gerenciamento para evitar vazamentos de memória.
  • Nome da Função de Callback: O nome da função de callback deve ser único no escopo global para evitar conflitos.
  • Tratamento de Erros: Devido às políticas de segurança do navegador, o tratamento de erros em requisições JSONP pode ser menos direto.

É recomendado priorizar o uso de CORS em vez de JSONP, pois JSONP possui limitações funcionais e de segurança, especialmente em aplicações web modernas que lidam com interações de dados complexas.

  1. Tratamento de Requisições Cross-Domain no Backend com Servlet

3.1 Teoria do Tratamento de Requisições Cross-Domain em Servlets

3.1.1 Política de Mesma Origem em Servlets

A política de mesma origem é um recurso de segurança do navegador que restringe como um script carregado de uma origem (protocolo, domínio e porta) pode interagir com recursos de outra origem. Quando um frontend em um domínio tenta acessar um backend em outro domínio, essa política entra em jogo. Para permitir essa comunicação, é necessário configurar o backend para aceitar requisições cross-domain.

3.1.2 Necessidade de Tratamento de Requisições Cross-Domain em Servlets

Implementar CORS em aplicações baseadas em Servlet é essencial para arquiteturas com frontend e backend desacoplados. Permite que o front end acesse APIs hospedadas em domínios diferentes, garantindo a segurança e melhorando a experiência do usuário.

  • Segurança: O backend pode controlar explicitamente quais origens são permitidas, mitigando ataques como XSS e CSRF.
  • Experiência do Desenvolvedor: Facilita o desenvolvimento do frontend, eliminando preocupações com restrições cross-domain.

Para implementar isso, o backend precisa configurar cabeçalhos de resposta HTTP específicos, como Access-Control-Allow-Origin, informando ao navegador quais origens são permitidas.

3.2 Implementação Backend com Servlet

3.2.1 Implementação de Cross-Domain usando Servlet Filter

Um Servlet Filter é uma abordagem comum para gerenciar requisições cross-domain de forma centralizada, sem modificar o código das Servlets existentes.


import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

public class CorsFilter implements Filter {

   @Override
   public void init(FilterConfig filterConfig) throws ServletException {
       // Inicialização do filtro
   }

   @Override
   public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
           throws IOException, ServletException {
       HttpServletRequest request = (HttpServletRequest) req;
       HttpServletResponse response = (HttpServletResponse) res;

       // Define a origem permitida. "*" permite todas, mas é recomendável especificar o domínio do frontend.
       response.setHeader("Access-Control-Allow-Origin", "http://seufrontend.com");
       // Métodos HTTP permitidos
       response.setHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS");
       // Cabeçalhos permitidos na requisição
       response.setHeader("Access-Control-Allow-Headers", "Authorization, Content-Type");
       // Permite o envio de credenciais (cookies, etc.)
       response.setHeader("Access-Control-Allow-Credentials", "true");
       // Tempo de cache para requisições preflight (OPTIONS)
       response.setHeader("Access-Control-Max-Age", "3600");

       // Responde a requisições OPTIONS (preflight) com sucesso
       if (request.getMethod().equals("OPTIONS")) {
           response.setStatus(HttpServletResponse.SC_OK);
       } else {
           // Continua a cadeia de filtros/servlets
           chain.doFilter(request, response);
       }
   }

   @Override
   public void destroy() {
       // Limpeza do filtro
   }
}

Este Filter configura os cabeçalhos CORS essenciais. Ele também lida com requisições OPTIONS (preflight requests) que os navegadores enviam antes de requisições mais complexas.

3.2.2 Simplificando a Configuração com a Anotação @CrossOrigin (Spring Framework)

O Spring Framework oferece a anotação @CrossOrigin para simplificar a configuração CORS em Controllers.


import org.springframework.web.bind.annotation.CrossOrigin;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class ResourceController {

   @CrossOrigin(origins = {"http://seufrontend.com", "http://outrofrontend.com"})
   @GetMapping("/dados")
   public String getDados() {
       return "Dados confidenciais.";
   }
}

A anotação @CrossOrigin pode ser aplicada em nível de classe ou método, permitindo especificar as origens permitidas, métodos, cabeçalhos, etc. O Spring Boot também oferece configurações globais através da interface WebMvcConfigurer.

  1. Mecanismo CORS e sua Aplicação Frontend-Backend

CORS (Cross-Origin Resource Sharing) é um mecanismo baseado em cabeçalhos HTTP que permite que um domínio solicite recursos de outro domínio. Ele adiciona flexibilidade ao desenvolvimento web, mas requer atenção à segurança.

4.1 Princípios do Mecanismo CORS

4.1.1 Requisições Preflight e Respostas CORS

Requisições Preflight (usando o método OPTIONS) são enviadas pelo navegador antes de requisições que podem ser consideradas "complexas" (métodos não simples ou com cabeçalhos customizados). A resposta a uma requisição preflight deve conter cabeçalhos como:

  • Access-Control-Allow-Origin: Especifica quais origens são permitidas.
  • Access-Control-Allow-Methods: Lista os métodos HTTP permitidos.
  • Access-Control-Allow-Headers: Indica quais cabeçalhos HTTP são permitidos na requisição real.

Após a aprovação da requisição preflight, a requisição HTTP principal é enviada.

4.1.2 Limitações de Segurança e Exceções em CORS

Nem todas as requisições cross-domain são permitidas por CORS:

  • Requisições "simples" (GET, HEAD, POST com Content-Type específico) não disparam preflight.
  • Requisições com métodos não simples (PUT, DELETE) ou cabeçalhos customizados disparam preflight.
  • Access-Control-Allow-Origin: * permite acesso de qualquer domínio, mas não suporta credenciais (cookies).

4.2 Casos de Uso de CORS em Frontend e Backend

4.2.1 Configuração Frontend para Requisições CORS

Na maioria dos casos, os navegadores modernos gerenciam requisições CORS automaticamente. O desenvolvedor frontend precisa garantir que o backend esteja configurado corrretamente.


// Usando a API Fetch
fetch('http://api.outrodominio.com/recurso', {
 method: 'GET',
 headers: {
   'Accept': 'application/json'
 }
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Erro:', error));

4.2.2 Configuração Backend CORS para Suporte a Cross-Domain

No backend, a configuração varia conforme a tecnologia. Em Node.js com Express:


const express = require('express');
const cors = require('cors');
const app = express();

const corsOptions = {
 origin: 'http://seufrontend.com', // Origem permitida
 methods: 'GET,POST', // Métodos permitidos
 allowedHeaders: 'Content-Type,Authorization', // Cabeçalhos permitidos
 credentials: true // Permitir credenciais
};

app.use(cors(corsOptions));

app.get('/dados', (req, res) => {
 res.json({ mensagem: "Dados da API" });
});

app.listen(3000, () => console.log('Servidor rodando na porta 3000'));

É crucial configurar CORS de forma específica e segura, especialmente em produção.

  1. Configuração de Cabeçalhos HTTP de Resposta para Interação Cross-Domain

5.1 Propósito dos Cabeçalhos HTTP Comuns

5.1.1 Propósito e Configuração de Access-Control-Allow-Origin

Este cabeçalho define quais origens podem acessar o recurso. Em uma configuração Spring Boot:


import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class CorsConfig implements WebMvcConfigurer {
   @Override
   public void addCorsMappings(CorsRegistry registry) {
       registry.addMapping("/api/**")
               .allowedOrigins("http://seufrontend.com")
               .allowedMethods("GET", "POST", "PUT", "DELETE")
               .allowedHeaders("Authorization", "Content-Type");
   }
}

5.1.2 Propósito e Configuração de Access-Control-Allow-Methods

Especifica os métodos HTTP permitidos para requisições cross-domain. O exemplo acima no CorsConfig já inclui allowedMethods.

5.2 Configuração Avançada de Cabeçalhos HTTP

5.2.1 Configuração de Access-Control-Allow-Headers

Permite que o frontend envie cabeçalhos customizados. No CorsConfig, é feito via allowedHeaders.

5.2.2 Configuração de Access-Control-Allow-Credentials

Controla se o navegador deve enviar cookies ou informações de autenticação em requisições cross-domain. Para permitir credenciais, o servidor deve expor Access-Control-Allow-Credentials: true e especificar uma origem única (não *) em Access-Control-Allow-Origin.


// Dentro do addCorsMappings
registry.addMapping("/api/**")
       .allowedOrigins("http://seufrontend.com")
       .allowCredentials(true); // Habilita envio de credenciais
  1. Soluções e Práticas de Código para Problemas de Ajax Cross-Domain

6.1 Geração e Impacto do Problema Cross-Domain

6.1.1 Definição do Problema Cross-Domain

O problema cross-domain surge da política de mesma origem (Same-Origin Policy) dos navegadores, que restringe a interação entre scripts de origens diferentes (protocolo, domínio, porta).

6.1.2 Escopo do Impacto

Afeta principalmente requisições HTTP feitas por Ajax (XMLHttpRequest, fetch) a partir de um domínio para outro.

6.1.3 Desafios Apresentados

Requer estratégias como proxy reverso no backend ou configuração de CORS para permitir a comunicação segura.

6.2 Detalhes Técnicos das Soluções Cross-Domain

6.2.1 Técnica JSONP

Utiliza a tag <script>, que não está sujeita à política de mesma origem. O servidor envolve os dados JSON em uma chamada de função de callback.


// Frontend
function callbackHandler(data) {
 console.log("Dados via JSONP:", data);
}
const script = document.createElement('script');
script.src = 'http://api.exemplo.com/data?callback=callbackHandler';
document.head.appendChild(script);

6.2.2 Implementação da Política CORS

O backend adiciona cabeçalhos de resposta HTTP (ex: Access-Control-Allow-Origin) para indicar ao navegador quais origens são permitidas.


// Backend (Servlet)
response.setHeader("Access-Control-Allow-Origin", "http://seufrontend.com");
response.setHeader("Access-Control-Allow-Methods", "GET, POST, OPTIONS");

6.2.3 Configuração Avançada de CORS

Inclui cabeçalhos como Access-Control-Allow-Headers para cabeçalhos customizados e Access-Control-Allow-Credentials para permitir cookies.


// Backend (Servlet)
response.setHeader("Access-Control-Allow-Headers", "Content-Type, Authorization");
response.setHeader("Access-Control-Allow-Credentials", "true");

Em produção, especifique origens e cabeçalhos permitidos em vez de usar *.

6.3 Estudo de Caso: Configuração Frontend e Implementação Backend

6.3.1 Configuração Frontend para Requisições CORS

Navegadores modernos tratam requisições CORS automaticamente. O frontend pode precisar lidar com requisições preflight OPTIONS em cenários específicos.


// Requisição preflight com Fetch API
fetch('http://api.exemplo.com/recurso', {
 method: 'OPTIONS',
 headers: {
   'Access-Control-Request-Method': 'POST',
   'Access-Control-Request-Headers': 'Content-Type'
 }
})
.then(response => console.log(response));

6.3.2 Configuração Backend CORS para Suporte a Cross-Domain

Exemplo com Node.js e Express usando o middleware cors:


const express = require('express');
const cors = require('cors');
const app = express();

const corsOptionsDelegate = (req, callback) => {
 let corsOptions;
 const origin = req.header('Origin');
 if (origin === 'http://seufrontend.com') {
   corsOptions = { origin: true, credentials: true }; // Permite origem específica e credenciais
 } else {
   corsOptions = { origin: false }; // Rejeita outras origens
 }
 callback(null, corsOptions);
};

app.use(cors(corsOptionsDelegate));

6.4 Resumo e Perspectivas Futuras para Problemas Cross-Domain

CORS e JSONP são soluções estabelecidas para problemas cross-domain. O desenvolvimento contínuo de padrões web pode trazer novas abordagens mais seguras e eficientes.

  1. Proteção de Segurança: Estratégias e Melhores Práticas para Requisições Cross-Domain

7.1 Desafios de Segurança em Requisições Cross-Domain

7.1.1 Ataque de Clickjacking

Embora não diretamente ligado a requisições cross-domain, pode ser explorado em conjunto com vulnerabilidades de cross-domain.

7.1.2 Cross-Site Request Forgery (CSRF)

Aumenta o risco quando requisições cross-domain são feitas em diferentes sessões de usuário.

7.1.3 Cross-Site Scripting (XSS)

Pode ser usado para contaminar respostas de requisições cross-domain, afetando a aplicação receptora.

7.2 Estratégias de Proteção de Segurança Cross-Domain

7.2.1 Uso da Política CORS

Configuração correta de cabeçalhos CORS (Access-Control-Allow-Origin, Access-Control-Allow-Credentials) é fundamental para prevenir requisições maliciosas.

7.2.2 Segurança Baseada em Tokens

Utilizar tokens (como JWT) para autenticação em requisições cross-domain adiciona uma camada extra de segurança.

7.2.3 Validação de Requisições

Verificar a origem, métodos HTTP e tipos de conteúdo das requisições ajuda a identificar e bloquear requisições suspeitas.

7.3 Melhores Práticas para Requisições Cross-Domain

7.3.1 Uso Seguro de JSONP

JSONP deve ser usado com cautela, pois permite a execução de código JavaScript arbitrário. Use apenas com fontes confiáveis.

7.3.2 Configuração Segura de CORS

Restrinja Access-Control-Allow-Origin a domínios específicos e confiáveis. Evite usar Access-Control-Allow-Credentials: true com Access-Control-Allow-Origin: *.

7.3.3 Verificações de Segurança no Backend

Sempre valide requisições no backend, verificando cabeçalhos como Referer, tokens CSRF, e sanitizando todas as entradas para prevenir injeções.

7.3.4 Princípio do Menor Privilégio

Configure APIs e CORS com o mínimo de permissões necessário para a funcionalidade.

7.4 Análise de Caso Prático

7.4.1 Configuração de Segurança da API de Transações

Para uma API bancária, a configuração CORS seria rigorosa:


Access-Control-Allow-Origin: https://banco-confiavel.exemplo
Access-Control-Allow-Methods: POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true

7.4.2 Tratamento da Requisição do Cliente

O cliente deve incluir informações de autenticação e garantir que a requisição seja legítima:


function realizarTransacao() {
 const xhr = new XMLHttpRequest();
 xhr.open('POST', 'https://banco-confiavel.exemplo/api/transacoes', true);
 xhr.setRequestHeader('Authorization', 'Bearer SEU_TOKEN');
 xhr.withCredentials = true; // Necessário se o backend permitir credenciais
 xhr.onload = function() { /* Lidar com resposta */ };
 xhr.onerror = function() { /* Lidar com erro */ };
 xhr.send(JSON.stringify(dadosTransacao));
}

A correta configuração de cabeçalhos e políticas de segurança é vital para proteger aplicações web contra ataques.

Nota: Este conteúdo é uma reformulação técnica do material original, focando na explicação dos conceitos e na apresentação de exemplos de código em português.

Tags: ajax cross-domain CORS servlet javascript

Publicado em 7-25 01:27

Tags em Destaque

©2026 Doido Dev