javascript - peticiones - Una pregunta sobre solicitud de ajax de dominio cruzado(subdominio)

solicitud de origen cruzado bloqueada angular

Question

Digamos que tengo la página principal cargada desde http://www.example.com/index.html . En esa página hay un código js que hace una solicitud de ajax a http://n1.example.com//echo?message=hello . Cuando se recibe la respuesta, se actualiza un div en la página principal con el cuerpo de la respuesta.

¿Funcionará eso en todos los navegadores populares?

Editar:

La solución obvia es colocar un proxy delante de www.example.com y n1.example.com y configurarlo de manera que cada solicitud que vaya a un subrecurso de http://www.example.com/n1 se envíe a http://n1.example.com/ .

Answer 1

El dominio cruzado es completamente un tema diferente. Pero el subdominio cruzado es relativamente fácil. Todo lo que necesita hacer es establecer que document.domain sea el mismo tanto en la página principal como en la página iframe.

document.domain = "yourdomain.com"

Más información aquí

Nota: esta técnica solo te permitirá interactuar con iframes de los padres de tu dominio . No altera el origen enviado por XMLHttpRequest.

Answer 2

Escribí una solución para cross sub domain y ha estado trabajando para mis aplicaciones. Usé iframe y establecí document.domain = "domain.com" en ambos lados. Puedes encontrar mi solución en:

https://github.com/emphaticsunshine/Cross-sub-domain-solution

Answer 3

La solución más simple que encontré fue crear un php en tu subdominio e incluir tu archivo de función original dentro de él usando una ruta completa.

Ejemplo:

www.domain.com/ajax/this_is_where_the_php_is_called.php

Subdominio:

sub.domain.com

Crear: sub.domain.com/I_need_the_function.php

Dentro de I_need_the_function.php solo usa un include:

include_once ("/ server / path / public_html / ajax / this_is_where_the_php_is_called.php");

Ahora llame a sub.domain.com/I_need_the_function.php desde su javascript.

var sub="";
switch(window.location.hostname)
{
case "www.domain.com":
sub = "/ajax/this_is_where_the_php_is_called.php";
break;
case "domain.com":
sub = "";
break;
default: ///your subdomain (or add more "case" ''s)
sub = "/I_need_the_function.php";
}
xmlHttp.open("GET",sub,true);

El ejemplo es tan simple como puedo hacerlo. Es posible que desee utilizar rutas mejor formateadas.

Espero que esto ayude a alguien. Nada desordenado aquí, y está llamando al archivo original, por lo que cualquier modificación se aplicará a todas las funciones.

Answer 4

Nueva idea: si quieres el subdominio cruzado (www.domain.com y sub.domain.com) y estás trabajando en apache. las cosas pueden ser mucho más fáciles. si un subdominio en realidad es un subdirectorio en public_html (sub.domain.com = www.domain.com/sub/. entonces si tiene ajax.domain.com/?request=subject... puede hacer algo como esto: www .domain.com / ajax /? request = asunto

¡funciona como un amuleto para mí, y no hay trucos estúpidos, proxies o cosas difíciles de hacer para unas pocas solicitudes de Ajax!

Answer 5

Otra solución consiste en dirigir la solicitud de Ajax a una página php (por ejemplo) en su dominio, y en esa página hacer una solicitud de cURL al subdominio.

Answer 6

Otra solución que puede funcionar o no para usted es insertar / eliminar dinámicamente etiquetas de guiones en su DOM que apuntan al dominio de destino. Esto funcionará si el objetivo devuelve json y admite una devolución de llamada.

Función para manejar el resultado:

<script type="text/javascript">
function foo(result) {
alert( result );
}
</script>

En lugar de hacer una solicitud AJAX, inserta dinámicamente algo como esto:

<script type="text/javascript" src="http://n1.example.com/echo?callback=foo"></script>

Answer 7

Todos los navegadores modernos admiten CORS y de ahora en adelante debemos aprovechar esta adición.

Funciona en la técnica de handshaking simple donde los dos dominios se comunican mutuamente a través de encabezados HTTP enviados / recibidos. Esto fue esperado ya que la misma política de origen era necesaria para evitar XSS y otros intentos maliciosos.

Para iniciar una solicitud de origen cruzado, un navegador envía la solicitud con un encabezado HTTP de origen. El valor de este encabezado es el sitio que sirvió a la página. Por ejemplo, supongamos que una página en http://www.example-social-network.com intenta acceder a los datos de un usuario en online-personal-calendar.com. Si el navegador del usuario implementa CORS, se enviaría el siguiente encabezado de solicitud:

Origen: http://www.example-social-network.com

Si online-personal-calendar.com permite la solicitud, envía un encabezado Access-Control-Allow-Origin en su respuesta. El valor del encabezado indica qué sitios de origen están permitidos. Por ejemplo, una respuesta a la solicitud anterior contendría lo siguiente:

Access-Control-Allow-Origin: http://www.example-social-network.com

Si el servidor no permite la solicitud de origen cruzado, el navegador enviará un error a la página example-social-network.com en lugar de la respuesta online-personal-calendar.com.

Para permitir el acceso a todas las páginas, un servidor puede enviar el siguiente encabezado de respuesta:

Access-Control-Allow-Origin: *

Sin embargo, esto podría no ser apropiado para situaciones en las que la seguridad es una preocupación.

Muy bien explicado aquí en la página wiki debajo. http://en.wikipedia.org/wiki/Cross-origin_resource_sharing