O desenvolvimento da Web geralmente requer enfrentar problemas de domínio cruzado. A causa raiz dos problemas de domínio cruzado é a estratégia do mesmo origem na segurança do navegador. Por exemplo, para http://www.a.com/1.html:
1. Http://www.a.com/2.html é homólogo;
2. Https://www.a.com/2.html é de fontes diferentes, porque o protocolo é diferente;
3. Http://www.a.com:8080/2.html é de diferentes fontes, porque as portas são diferentes;
4. Http://sub.a.com/2.html é de fontes diferentes porque os hosts são diferentes.
No navegador, as tags <Script>, <mg>, <frame> e <link> podem carregar recursos de domínio cruzado (não homólogo), e o método de carregamento é realmente equivalente a uma solicitação GET comum. A única diferença é que, por uma questão de segurança, o navegador não permite operações de leitura e gravação nos recursos carregados dessa maneira, mas só pode usar os recursos que a própria tag deve ter (como execução de script, aplicação de estilo etc.).
O problema mais comum de domínio cruzado é o problema de acesso ao domínio cruzado do Ajax. Por padrão, os URLs de domínio cruzado não podem ser acessados através do AJAX. Aqui eu gravo o que aprendi sobre os métodos de domínio cruzado:
1. Proxy do lado do servidor , não há nada a dizer. A desvantagem é que, por padrão, o servidor que recebe solicitações de AJAX não pode obter o IP e o UA do cliente.
2. Iframe , o uso do iframe é realmente equivalente à abertura de uma nova página da web. O método específico de domínio cruzado é aproximadamente a página pai aberta pelo domínio A ninhos de um iframe apontando para o domínio B e depois envia os dados. Após a conclusão, o servidor de B pode:
● Retorne uma resposta de redirecionamento 302 e aponte o resultado de volta ao domínio A;
● Ninhe um iframe apontando para o domínio A dentro deste iframe.
Ambos finalmente implementam chamadas de domínio cruzado. Esse método é mais funcionalmente mais forte do que o JSONP introduzido abaixo, porque após a conclusão do domínio cruzado, não há problema com as operações do DOM e as chamadas de JavaScript entre si, mas há algumas restrições, como o resultado que está sendo aprovado nos parâmetros de URL, o que significa que os dados do resultado são grandes, precisam ser aprovados na segmentação, o que é muito preocupante; Há outro problema causado pelo próprio iframe, e a interação entre a página pai e o próprio iframe tem restrições de segurança.
3. Use tags de script para domínio cruzado , esse método também é muito comum. As tags de script podem carregar JavaScript estranhas e executá -las. A função de retorno de chamada predefinida pode realizar interação com a página pai. Ele tem um grande nome chamado JSONP Cross Domain, que é uma abreviação para JSON com estofamento. É um protocolo não oficial, que obviamente está carregando o script, então por que está relacionado ao JSON? Acontece que é essa função de retorno de chamada. Existe uma maneira típica de usá -lo, que é passar os parâmetros pelo JSON, ou seja, preencher os dados JSON na função de retorno de chamada. Este é o significado do json+preenchimento do JSONP.
Existem muitos serviços JSONP na Internet para fornecer dados. Em essência, são solicitações de domínio cruzado e especificam retornos de chamada no URL da solicitação, como o retorno de chamada = resultado. Após obter esses dados, a função de resultado será chamada automaticamente e os dados serão transmitidos na forma de JSON, por exemplo (pesquise "futebol"):
http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=football&callback=result
Use jQuery para chamá -lo e escreva como:
A cópia do código é a seguinte:
$ .getjson ("http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=football&callback=?", function (dados) {
// ...
});
Em geral, a limitação da abordagem de domínio cruzado do JSONP é que ela só pode usar as solicitações GET e não pode resolver o problema de como fazer chamadas de JavaScript entre duas páginas em diferentes domínios.
4. Domínio cruzado do flash:
Ele acessará o arquivo crossDomain.xml no diretório raiz do site de destino e determinará se deve permitir esse acesso de domínio cruzado com base no conteúdo do arquivo:
A cópia do código é a seguinte:
<policy-policy>
<allow-access-from domain = "xxx.xxx.com" />
</fomination-policy>
5. A tag IMG também pode ser usada , o que também é um método muito comum. Ele tem uma função mais fraca e só pode enviar uma solicitação GET sem retornos de chamada. É assim que a contagem de cliques do Google é determinada.
6. Window.PostMessage, que é um mecanismo recém-adicionado para comunicação entre domínios, é suportado apenas pelo Firefox 3, Safari 4, IE8 e versões posteriores. A chamada para usá -lo para enviar mensagens para outras janelas é a seguinte:
A cópia do código é a seguinte:
outrowindow.postMessage (mensagem, Targetorigin);
Na janela receptora, um manipulador de eventos precisa ser definido para receber as mensagens enviadas:
A cópia do código é a seguinte:
window.addeventListener ("mensagem", recebimento, false);
Função RECEVEMESSAGE (Evento) {
if (event.orgin! == "http://example.org:8080")
retornar;
}
Observe que os atributos de origem e origem da mensagem devem ser usados para verificar a identidade do remetente, caso contrário, ela causará vulnerabilidades XSS.
7. Controle de acesso
Alguns navegadores suportam cabeçalhos de resposta, como o Access-Control-Arn-Origin, como:
A cópia do código é a seguinte:
Cabeçalho ("Access-Control-Allow-Origin: http://www.a.com");
Isso especifica que o acesso ao domínio cruzado ao www.a.com é permitido.
8. Window.name
Essa coisa foi realmente usada como um meio de invadir XSS. A essência é que, quando o local da janela muda, a página será recarregada, mas, curiosamente, a janela. O nome não muda, para que você possa usá -lo para passar o valor. Com o iframe, altere o objeto de janela do IFRAME várias vezes e a transferência de dados de domínio cruzado é concluído.
9. Document.Domain
Este método é adequado para comunicação entre domínios, como A.example.com e B.Example.com, porque os dois têm um domínio comum chamado exemplo.com. Basta definir document.Domain como exemplo.com, mas se você deseja se comunicar entre a.example1.com e b.example2.com, ele não tem escolha.
10. Mensagens Identitier de Fragmento (FIM)
Este método é muito interessante e requer a cooperação de iframes. Fragment Identitier é a parte que é frequentemente usada para o posicionamento da âncora após a marca de libra do URL (#). As alterações nesta parte não causarão atualização da página. A janela feminina pode acessar o URL do iframe à vontade e o Iframe também pode acessar o URL da janela feminina. Em seguida, a comunicação pode ser alcançada alterando o identificador de fragmentos. A desvantagem é que as mudanças no FragMement Identitier gerarão histórico desnecessário e terão restrições de comprimento; Além disso, alguns navegadores não suportam o evento ONHASHCHANGE.
11. Frame cruzado (CF)
Este método é uma variante do método FIM acima. A essência de CF e FIM é realmente introduzida no meu artigo "GWT First Experience" (é usado apenas para implementar o histórico e as funções atrasadas). Ele criará dinamicamente um iframe invisível, apontando para um domínio estranho. Após o processamento, o Fragment Identitier no URL deste IFRAME contém os resultados do processamento para a página pai para acessar, enquanto o URL do navegador não tem alterações.
12. Cookie+Protocolo P3P
Usar as características dos cookies de acesso aos domínios cruzados no protocolo P3P para obter acesso ao domínio cruzado também é um truque estranho. O P3P é um padrão de recomendação de proteção à privacidade divulgado pelo W3C, com o objetivo de fornecer proteção à privacidade para usuários da Internet que navegam na Internet. Defina o caminho do cookie como "/", isto é, não há restrição de domínio. Neste momento, alguns navegadores permitem que páginas de outros URLs sejam lidas, enquanto outros não. Nesse caso, o cabeçalho P3P precisa ser definido na cabeça da resposta da página pai:
A cópia do código é a seguinte:
P3P: cp = "Cura Adma deva PSAO PSDO Nosso ônibus uni pur int Dem sta pré -com nav OTC noi dsp cor"