2008-11-25 14 views
10

Aquí está el problema:Cruz dominio petición Ajax desde dentro del archivo js

1.) Tenemos página de aquí ... www.blah.com/mypage.html

2.) Que solicita una página de JS presentar www.foo.com así ...

<script type="text/javascript" src="http://www.foo.com/jsfile.js" /> 

3.) "jsfile.js" Prototipo utiliza para hacer una petición Ajax de nuevo a www.foo.com.

4.) La solicitud de ajax llama a www.foo.com/blah.html. La función de devolución de llamada obtiene la respuesta html y la arroja a un div.

Esto no parece funcionar, supongo que es XSS. ¿Es eso correcto?

En caso afirmativo, ¿cómo puedo resolver este problema? ¿Hay alguna otra forma de obtener mi html de www.foo.com a www.blah.com en el cliente sin usar un iframe?

+1

Realmente hay un buen artículo sobre la solicitud de ayax de dominio cruzado - http://tek-insight.blogspot.com/2010/05/cross-domain-ajax-request-proxy-json.html –

Respuesta

14

Es XSS y está prohibido. Realmente no deberías hacer las cosas de esa manera.

Si realmente lo necesita, haga que su código AJAX llame al código local (PHP, ASP, lo que sea) en blah.com y haga que se comporte como cliente y busque lo que necesite de foo.com y devuélvalo a la cliente. Si usa PHP, puede hacerlo con fopen ('www.foo.com/blah.html', 'r') y luego leer el contenido como si fuera un archivo normal.

Por supuesto, allow_remote_url_fopen (o como se llame exactamente) debe estar habilitado en su php.ini.

2

Una opción es implementar una página de proxy que tome la url necesaria como parámetro. p.ej. http://blah.com/proxy?uri=http://foo.com/actualRequest

+2

Será mejor que hagas una pequeña validación para asegurarse de que la URL sea la que usted espera ... de lo contrario, es un gran agujero de seguridad. – rmeador

+1

Por supuesto. Pensé que estaba implícito cuando dije "implementar". – Rohit

0

El método mostrado arriba podría convertirse en un gran agujero de seguridad. Le sugerimos que verifique el nombre del sitio con una lista blanca y que construya el URI real que está siendo procesado en el lado del servidor.

6

Hay un w3c proposal para permitir que los sitios especifiquen otros sitios que pueden hacer consultas entre ellos. (Wikipedia podría querer permitir todas las solicitudes de artículos, por ejemplo, pero el correo de google no querría permitir solicitudes, ya que esto podría permitir que cualquier sitio web se abra cuando haya iniciado sesión en google mail para leer su correo).

Esto podría estar disponible en algún momento en el futuro.

+3

La propuesta actual del W3C se llama ["Intercambio de recursos de origen cruzado"] (http://www.w3.org/TR/cors/), comúnmente conocida como ** 'CORS' **. – hippietrail

0

Para éxitos de dominio cruzados este es un buen ejemplo de trabajo y ahora se considera como algo así como "estándar" http://www.xml.com/pub/a/2005/12/21/json-dynamic-script-tag.html.

hay otras maneras también, por ejemplo, la inyección de marcos flotantes con document.domain alterados

http://fettig.net/weblog/2005/11/28/how-to-make-xmlhttprequest-connections-to-another-server-in-your-domain/

Todavía Agre que el camino más fácil está llamando a un proxy en el mismo dominio, pero entonces no es verdaderamente lado del cliente Llamada de WS

3

Como se mencionó anteriormente JSONP es una manera de evitar esto. Sin embargo, el sitio del que solicita los datos debe ser compatible con JSONP para que pueda usarlo en el cliente. (JSONP inyecta esencialmente una etiqueta de script en la página y proporciona una función de devolución de llamada que se debe invocar con los resultados)

Si el sitio al que hace una solicitud no es compatible con JSONP, deberá enviar la solicitud por proxy a su servidor. Como se mencionó anteriormente, puede hacer esto en su propio servidor o lo que he hecho en el pasado es usar http://www.jsonpit.com, que sustituirá la solicitud por usted.

Cuestiones relacionadas