English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
Resumen de conocimientos sobre acceso entre dominios de JS:
Antes de que la palabra "acceso entre dominios" apareciera con frecuencia, ya la estábamos utilizando con frecuencia. Por ejemplo, en el img de un sitio web A, src apunta a una dirección de imagen en un sitio web B, sin duda, en la mayoría de los casos, esto se puede mostrar normalmente (sin mencionar la tecnología de prevención de enlace robado); del mismo modo, se puede hacer que el atributo src de la etiqueta script apunte a recursos de scripts en otros sitios web (en algunos casos, incluso se alienta a hacerlo, para aprovechar al máximo las ventajas de carga de otros sitios web, reducir la cantidad de acceso concurrente de su propio servidor). Sin embargo, si se utiliza js para solicitar datos de otros sitios web de manera activa, como el método AJAX, se encontrará con problemas de acceso entre dominios que son muy molestos, esto es lo que llamamos acceso entre dominios. Por razones de seguridad, el acceso entre dominios está prohibido por defecto por todos los navegadores. Esto involucra el concepto de política de origen: la política de origen impide que un script cargado en un dominio acceda o manipule las propiedades del documento de otro dominio. Es decir, el dominio de la URL solicitada debe ser el mismo que el dominio del página web actual. Esto significa que el navegador aísla el contenido de diferentes orígenes para evitar que operen entre ellos.
El problema de seguridad específico que conlleva el acceso entre dominios no ha sido investigado a fondo, todos pueden completar mentalmente.
Sin embargo, en muchos casos, especialmente en la actualidad, cuando Internet sigue desarrollándose, necesitamos solicitar interfaces de frontend de diferentes socios o proveedores de datos, antes de que se estandarice el modo de acceso entre dominios (se ve que la necesidad de acceso entre dominios del lado del cliente también ha llamado la atención de w3Atención, c, según lo que dicen, html5 El estándar WebSocket admite el intercambio de datos entre dominios, también debería ser una solución de intercambio de datos entre dominios opcional en el futuro, ¿cuál es el método para evitar sus limitaciones? Hay muchas respuestas (aunque todas son bastante complicadas), la más común es lo que se conoce como JSONP entre dominios.
Principio de JSONP
El principio más básico de JSONP es: agregar dinámicamente una etiqueta <script>, y el atributo src de la etiqueta <script> no tiene limitaciones de otro dominio. Por lo tanto, este método de otro dominio no tiene nada que ver con el protocolo XmlHttpRequest de ajax.
JSONP es JSON con Relleno. Debido a las limitaciones de la política de origen, XmlHttpRequest solo permite solicitudes de recursos de la fuente actual (dominio, protocolo, puerto). Si se desea realizar solicitudes de otro dominio, podemos usar la etiqueta script de html para realizar solicitudes de otro dominio y devolver el código script a ejecutar en la respuesta. Este método de comunicación de otro dominio se llama JSONP.
Ejemplo simple:
!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>
Resumen del principio y proceso: Primero, registre un callback en el cliente, luego envíe el nombre del callback al servidor (aquí, el cliente y el servidor acuerdan transmitir el valor de la consulta de cadena de key como jsonp). En este momento, el servidor genera datos json. Luego, genera una función en la forma de sintaxis de javascript, y el nombre de la función es el parámetro transmitido anteriormente jsonp. Finalmente, coloca los datos json directamente como parámetro en la función, de esta manera se genera un documento de sintaxis de js, que se devuelve al cliente. El navegador del cliente analiza la etiqueta script y ejecuta el documento de javascript devuelto, lo que significa que se ejecutó la función callback predefinida.
A partir de la descripción anterior, se puede deducir: además de devolver fragmentos de código js en forma de función, el servidor puede naturalmente devolver todos los fragmentos de js ejecutables que cumplan con los estándares.}
Las desventajas de JSONP son: solo admite solicitudes GET y no admite otros tipos de solicitudes HTTP como POST; solo admite solicitudes HTTP de dominio cruzado, no puede resolver el problema de cómo realizar llamadas JavaScript entre dos páginas de diferentes dominios. (A continuación, se mencionará)
jQuery Jsonp
Como se mencionó anteriormente, jsonp no es una solicitud ajax, pero jQuery aún proporciona una forma de solicitud de dominio cruzado idéntica a jQuery.ajax:
$.ajax({
url: 'http://crossdomain.com/jsonServerResponse',
type: 'GET',
dataType: 'jsonp',
jsonp: "callback",
jsonpCallback: 'functionName',
success: function (data, textStatus, jqXHR) { }
//……
});
Como se muestra anteriormente, al establecer dataType en jsonp indica que se realiza una solicitud de dominio cruzado, jsonp se establece como la clave de consulta del nombre de la función transmitida por el servidor, y jsonpCallback es el nombre de la función js; si jsonpCallback no se establece, jQuery generará automáticamente un nombre de función aleatorio (cargar una función global en el objeto window, ejecutarla cuando se inserte el código, y luego se eliminará), se puede inferir que la función generada automáticamente realizará la retroalimentación de la función success en el código anterior. (Cuando se asigna manualmente a jsonpCallback, ¿no se llamará la función success o jQuery buscará la función predefinida, y si no la encuentra, se generará un error? El blogger es perezoso, lo probaré más tarde). Por supuesto, jQuery nos proporciona una versión sencilla, $.getJSON, aquí no se detallará.
Es necesario prestar atención al parámetro jqXHR de la función success, en las solicitudes ajax, es el objeto jqXHR auténtico, también puede considerarse como el objeto XMLHTTPRequest (heredado o encapsulado), pero en las solicitudes jsonp no es así, prácticamente no nos ofrece la información tan útil como la de XMLHTTPRequest: le falta la información de estado de solicitud de XMLHTTPRequest, por lo que no puede activar la mayoría de las funciones de retroalimentación, como error, complete, etc. (jQuery1.9.0), y debería poder ser deducido por la función success que puede ser invocada por el evento load del elemento script, lo que es completamente diferente del mecanismo de estado de XMLHTTPRequest utilizado por ajax. Después de experimentar, zepto (v1.1.3），en caso de errores en la solicitud jsonp, como cuando se carga el documento js y se devuelve en la cabecera401Cuando ocurre un error, la función error se ejecutará, pero el parámetro jqXHR de esta función tampoco es del tipo jqXHR auténtico, incluso no se puede obtener la información de encabezado de respuesta a través de él. En este caso, solo se nos informa de que algo salió mal, pero no se conoce la información específica del error. En escenarios similares donde la respuesta de encabezado lleva información útil, el autor no recomienda usar jsonp. Se puede decir que un prerequisite para el uso de jsonp es: además de excepciones no relacionadas con el negocio como errores de red, todas las excepciones de negocio (en términos generales, todas las excepciones lanzadas durante el período desde la recepción de la solicitud del servidor hasta la respuesta) deben devolverse directamente en la forma de resultado de la solicitud al cliente, lo que facilita que el cliente realice análisis de retroalimentación.
Gracias por leer, espero que pueda ayudar a todos. ¡Gracias por el apoyo a este sitio!
Declaración: El contenido de este artículo se ha obtenido de la red, y los derechos de autor pertenecen a los propietarios originales. El contenido ha sido contribuido y subido por usuarios de Internet de manera autónoma. Este sitio no posee los derechos de propiedad, no ha sido editado por humanos y no asume ninguna responsabilidad legal relacionada. Si encuentra contenido sospechoso de infracción de derechos de autor, le invitamos a enviar un correo electrónico a: notice#oldtoolbag.com (al enviar un correo electrónico, reemplace # con @) para denunciar, y proporcione evidencia relevante. Una vez verificada, este sitio eliminará inmediatamente el contenido sospechoso de infracción.