Una pregunta sobre el dominio cruzado (subdominio) solicitud ajax

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 al 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 poner un proxy delante de www.example.com y n1.example.com y configurarlo para que cada petición de ir a un subrecurso de http://www.example.com/n1 se aproxima a http://n1.example.com/.

Answer 1

Otra solución que puede funcionar o no para usted es insertar/eliminar dinámicamente etiquetas de script 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 gestionar el resultado:

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

En vez de hacer una petición AJAX debería insertar dinámicamente algo como esto:

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

Answer 2

Otra solución, es dirigir la solicitud ajax a un php (por ejemplo) página en su dominio, y en esa página haga una solicitud de cursl al subdominio.

Answer 3

El dominio cruzado es completamente 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" 

More info here

Nota: esta técnica will only let you interact with iframes from parents of your domain. Hace no altera el origen enviado por XMLHttpRequest.

Answer 4

Nueva idea: si quiere el subdominio cruzado (www.domain.com y sub.domain.com) y está 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 .dominio.com/ajax /? = solicitud sujetos

funciona como un encanto para mí, y sin trucos estúpidos, proxys o cosas difíciles de hacer por sólo unas pocas peticiones Ajax!

Answer 5

escribí una solución de cruz . sub dominio y su estado trabajando para mis aplicaciones solía marco flotante y el establecimiento de document.domain = "domain.com" en ambos lados puede encontrar mi solución a:.

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

Answer 6

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

Ejemplo:

www.domain.com/ajax/this_is_where_the_php_is_called~~V~~3rd.php

subdominio:

sub.domain.com

Crear: sub.domain.com/I_need_the_function.php

Dentro I_need_the_function.php sólo tiene que utilizar un incluir:

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 7

Todos los navegadores modernos son compatibles con 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 por medio 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, el siguiente encabezado de la solicitud sería enviado:

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 petición anterior contendría lo siguiente:

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

Si el servidor no permite la solicitud de origen cruzado, el navegador entregará un error 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 la siguiente cabecera de respuesta:

Access-Control-Allow-Origen: *

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

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