Introdução detalhada ao conhecimento de cross-domain do Javascript

Resumo de conhecimento sobre troca de domínios JS:

Antes de o termo 'troca de domínios' aparecer frequentemente, já o usamos frequentemente. Por exemplo, no site A, o img src aponta para um endereço de imagem em um site B, sem dúvida, isso pode ser exibido normalmente (sem mencionar a tecnologia de prevenção de roubo de link); da mesma forma, pode-se fazer com que o atributo src do tag script aponte para recursos de scripts em outros sites (em alguns casos, até encorajar isso, para aproveitar ao máximo as vantagens de carga de outros sites, reduzir a quantidade de concorrência no servidor próprio). No entanto, se usar js para solicitar dados de outros sites ativamente, como o método ajax, encontrará problemas de troca de domínios irritantes, isso é o que chamamos de troca de domínios. Por razões de segurança, o acesso entre domínios é proibido por padrão por todos os navegadores. Isso envolve o conceito de política de origem: a política de origem impede que scripts carregados de um domínio obtenham ou operem atributos de documentos de outro domínio. Isso significa que o domínio da URL solicitada deve ser o mesmo que o domínio da página web atual. Isso significa que os navegadores isolam o conteúdo de diferentes origens para evitar operações entre eles.

Os problemas de segurança específicos da troca de domínios não foram profundamente investigados pelo blogueiro, todos podem preencher mentalmente.

No entanto, em muitos casos, especialmente no atual desenvolvimento contínuo da Internet, precisamos solicitar interfaces de frontend de diferentes parceiros ou provedores de dados, antes que o acesso entre domínios seja padronizado (a demanda por acesso entre domínios no cliente também parece ter引起w3Atenção, c, conforme informado nos documentos html5 O padrão WebSocket suporta a troca de dados entre domínios, também deve ser uma solução opcional para a troca de dados entre domínios no futuro, quais são as maneiras de contornar suas limitações? Existem muitas maneiras (embora todas sejam complicadas), a mais comum é o chamado JSONP para contornar domínios.

Princípio do JSONP

O princípio mais básico do JSONP é: adicionar dinamicamente uma tag <script>, enquanto a propriedade src da tag <script> não tem restrições cross-domain. Dessa forma, este método cross-domain não tem relação com o protocolo XmlHttpRequest do Ajax.

JSONP é JSON com Padding. Devido às restrições da política de origem, XmlHttpRequest permite apenas recursos da origem atual (domínio, protocolo, porta). Para fazer solicitações cross-domain, podemos usar a tag html script para fazer solicitações cross-domain e retornar o código script a ser executado na resposta. Este método de comunicação cross-domain é chamado de JSONP.

Dê um exemplo simples:

!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" > 
<head> 
  <title>Test Jsonp</title> 
  <script type="text/javascript"> 
      function jsonpCallback(result) 
      { 
      alert(result.msg); 
      } 
    </script> 
  <script type="text/javascript" src="http://crossdomain.com/jsonServerResponse?jsonp=jsonpCallback"></script> 
</head> 
<body> 
</body> 
</html>

Breve descrição do princípio e processo: Primeiro, registre um callback no cliente, então passe o nome do callback para o servidor (aqui, o cliente e o servidor acordam passar o valor da query string com a chave jsonp). Neste momento, o servidor gera os dados json. Em seguida, gera uma função com a sintaxe do javascript, o nome da função é o parâmetro passado jsonp. Por fim, coloca os dados json diretamente como argumento da função, gerando assim um documento de sintaxe js, que é retornado para o cliente. O navegador do cliente解析a tag script e executa o documento javascript retornado, executando assim a função callback predefinida.

A partir da descrição resumida acima, pode-se concluir que, além de retornar fragmentos de código js em forma de função, o servidor naturalmente pode retornar todos os fragmentos de js executáveis que atendem aos padrões.

As desvantagens do JSONP são: ele suporta apenas solicitações GET e não suporta outros tipos de solicitações HTTP como POST; ele suporta apenas solicitações HTTP cross-domain, e não resolve o problema de como duas páginas diferentes de domínios diferentes podem chamar JavaScript umas das outras. (Ainda há mais a seguir)

jQuery Jsonp

Como mencionado anteriormente, jsonp não é uma solicitação AJAX, mas o jQuery ainda fornece um método de solicitação cross-domain idêntico ao jQuery.ajax:

$.ajax({
  url: 'http://crossdomain.com/jsonServerResponse',
  type: 'GET',
  dataType: 'jsonp',
  jsonp: "callback",
  jsonpCallback: 'functionName',
  success: function (data, textStatus, jqXHR) { }
  //……
});

Como mostrado acima, o dataType definido como jsonp indica que esta é uma solicitação cross-domain, jsonp define o nome da função de passagem previamente determinada pelo servidor como a chave da string de consulta, e jsonpCallback é o nome da função js; se jsonpCallback não for definido, o jQuery gerará automaticamente um nome de função aleatório (carregando uma função global no objeto window, que é executada quando o código é inserido e é removida após a execução), pode-se inferir que a função gerada automaticamente será chamada pela função success mencionada acima. (Quando se atribui manualmente ao jsonpCallback, não se sabe se a função success será chamada ou se o jQuery procurará uma função predefinida, e, se não encontrar, será emitido um erro? O blogueiro é preguiçoso, vamos tentar mais tarde.) Claro, o jQuery nos oferece uma versão simplificada, $.getJSON, que não será discutida aqui.

É necessário notar que o parâmetro jqXHR da função success, no contexto de solicitações AJAX, é um objeto jqXHR autêntico, também pode ser visto como um objeto XMLHTTPRequest (herança ou encapsulamento), mas não é o caso nas solicitações JSONP, quase não nos oferece as informações mais úteis do XMLHTTPRequest: falta a informação do estado da solicitação do XMLHTTPRequest, portanto, não pode acionar a maioria das funções de callback, como error, complete e outras (jQuery1.9.0), enquanto a função success que pode ser chamada deve ser acionada pelo evento load do tag script, o que é completamente diferente do mecanismo de estado do XMLHTTPRequest utilizado pelo ajax. Após a experiência, o Zepto (v1.1.3Em caso de erro na solicitação jsonp, por exemplo, ao carregar o documento js, a cabeça da resposta retorna401Quando ocorre um erro, a função error é executada, mas o parâmetro jqXHR da função também não é do tipo jqXHR original, nem pode obter informações de cabeçalho de resposta através dele. Neste caso, somos informados apenas de que algo está errado, mas não sabemos qual é o erro específico. Em situações semelhantes onde a cabeça da resposta carrega informações úteis, o blogueiro não recomenda o uso de jsonp. Diz-se que um dos pré-requisitos para o uso de jsonp é: além de exceções não triviais, como falhas de rede, todas as exceções de negócios (isto é, todas as exceções lançadas durante o período de solicitação ao servidor até a resposta) devem ser retornadas diretamente ao cliente na forma de resultados de solicitação, facilitando a análise de chamadas de volta pelo cliente.

Agradecemos a leitura e esperamos que ajude a todos. Obrigado pelo apoio ao site!

Declaração: O conteúdo deste artigo é de origem na internet, pertencente ao respectivo proprietário. O conteúdo é contribuído e carregado voluntariamente pelos usuários da internet. Este site não possui direitos de propriedade, não foi editado artificialmente e não assume responsabilidades legais relacionadas. Se você encontrar conteúdo suspeito de infringir direitos autorais, por favor, envie um e-mail para: notice#oldtoolbag.com (ao enviar e-mail, troque # por @ para denunciar e forneça provas relevantes. Atingida, o site deletará imediatamente o conteúdo suspeito de infringir direitos autorais.)

Manual básico