Este é um post disponível para assinantes MVP
dê seu feedback
post favorito
Comunicação AJAX Cross-Domain - Revista Java Magazine 97 - Parte 1
Aplicação do padrão W3C Cross-Origin Resource Sharing no desenvolvimento de sistemas que disponibilizem recursos consumíveis por aplicações de outros domínios através de chamadas AJAX, estendendo o conceito de segurança Same Origin Policy.
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 97
Com o crescimento e a popularização de APIs para o desenvolvimento de aplicações baseadas em AJAX, como jQuery e Prototype, é cada vez maior o número de aplicações Mashup escritas em JavaScript espalhadas pela internet. Estas aplicações combinam dados e códigos de diversas fontes de forma a criar novos serviços e funcionalidades.
Quando desenvolvemos este tipo de aplicação, encontramos algumas dificuldades quando a aplicação tenta realizar alguma forma de comunicação entre domínios distintos. Isso acontece porque os navegadores implementam o conceito de segurança Same Origin Policy (SOP). O SOP é aplicado a linguagens de programação que são executadas no navegador, como JavaScript, e limita o acesso à maioria das propriedades entre páginas de domínios diferentes, como funções JavaScript, cookies e dados de formulários, permitindo apenas que scripts rodando em páginas com o mesmo domínio, na mesma porta e através do mesmo protocolo acessem métodos e propriedades sem nenhum tipo de restrição.
Neste artigo abordaremos a utilização do padrão Cross-Origin
Resource Sharing para permitir requisições “client-side” entre diferentes
domínios, detalhando seu funcionamento teórico e demonstrando a sua aplicação
prática através de um estudo de caso.
O conceito de segurança Same Origin Policy
O Same Origin Policy (SOP) é um conceito importante de segurança que surgiu no navegador Netscape 2.0 e define as restrições de segurança que um JavaScript pode ou não realizar em uma página web. O SOP previne que um documento ou script carregado em um site de uma determinada origem recupere ou altere as propriedades de um documento de uma outra origem. Essas propriedades, que podem ser cookies ou mesmo dados de um formulário, só podem ser acessadas por scripts providos pela mesma origem, protegendo a integridade e a confidencialidade destas informações.
O termo origem é definido pela combinação do protocolo, nome
do domínio e, por último, a porta TCP do documento HTML que está rodando o
script. Por exemplo, http://foo.com:80 representa uma origem, onde HTTP é o protocolo
utilizado, foo.com é o domínio da aplicação web e 80 é a porta utilizada
para receber as requisições.
Imaginemos um código JavaScript carregado pela página http://provider.com.br/pagina.html tentando acessar propriedades de outras páginas. A Tabela 1 mostra o comportamento do navegador ao tentar se comunicar com cada origem apresentada na coluna URL.
A solução Cross-Origin Resource Sharing
O Cross-Origin Resource Sharing (CORS) é uma especificação que consiste na troca de cabeçalhos HTTP entre cliente e servidor permitindo o sucesso de requisições entre domínios diferentes. Desta forma os navegadores são capazes de realizar chamadas HTTP com o uso de scripts para outros domínios. Este tipo de mecanismo nos permite realizar o consumo de APIs de diversos provedores, não ficando restrito apenas ao uso do método HTTP Get, como no padrão JSONP.
Os navegadores que implementam esta especificação possuem recursos próprios para realizar tarefas inerentes ao processo de determinação e validação da origem das requisições, como autenticação HTTP, criação e manutenção de cookies e maneiras de comparar informações, especialmente na forma de cabeçalhos enviados por ambos os lados envolvidos na comunicação.
Como funciona
Os navegadores, como o Firefox 6 e Safari 5, utilizam o objeto XMLHttpRequest como um container da API que implementa as funcionalidades de um “cliente HTTP”. O Internet Explorer, nas versões 8 e 9, implementa parte desta API através do objeto XDomainRequest, que é similar ao XMLHttpRequest, e também funciona como um container.
Uma alternativa seria o uso da biblioteca JavaScript JQuery 1.5.1, ou superior, que encapsula a lógica de criação dos objetos XMLHttpRequest e XDomainRequest de acordo com o navegador e fornece uma interface amigável para utilização. O link da documentação encontra-se nas referências deste artigo.
Estes navegadores trabalham da seguinte maneira:
1. O cliente envia um cabeçalho chamado “ORIGIN”, que contém a origem da requisição, ou seja, protocolo, domínio e porta da página solicitante;
2. O servidor, adequadamente preparado para receber esta requisição, aceita ou não a origem informada, e em caso positivo, responde com o cabeçalho “Access-Control-Allow-Origin”, que indica os domínios com permissão de acesso ao recurso, ou o valor "*" (asterisco) se for um recurso público.
O padrão CORS trabalha adicionando novos cabeçalhos HTTP, nas requisições do cliente e nas respostas do servidor, que permitem aos servidores disponibilizarem recursos a origens autorizadas.
A Figura 1 demonstra como os navegadores trabalham, conforme o fluxo descrito acima.
A requisição "Preflighted"
A especificação obriga que requisições que não utilizem os verbos GET ou POST, ou mesmo requisições que utilizem POST para enviar dados com tipo de conteúdo diferente de application/x-www-form-urlencoded, multipart/form-data, ou text/plain e com cabeçalhos customizados sejam preflighted. Esta determinação serve para mitigar possíveis ataques contra os recursos disponibilizados, evitando assim que dados sensíveis possam ser alterados facilmente.
A requisição preflighted é uma requisição, com o verbo OPTIONS do HTTP e com o cabeçalho ORIGIN informando a origem solicitante, que acontece antes da requisição original. Com isto, o navegador descobre se o recurso solicitado está preparado para receber requisições de outras origens e se a origem solicitante tem acesso ao recurso desejado. Após este processo, caso a validação seja bem sucedida, o navegador dispara a requisição original. Esta funcionalidade não é suportada pelo objeto XDomainRequest do Internet Explorer 8 e 9, somente pelo objeto XMLHttpRequest. Esta limitação existe porque o Internet Explorer não implementa a especificação por completo.
O mecanismo de preflighted é transparente para o desenvolvedor web pois ele acontece automaticamente, sendo o navegador responsável por este tratamento.
"ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
0
0
