2010-01-14 13 views
9

Tengo un entorno que no permite el scripting del lado del servidor realmente (es extremadamente difícil obtener un script "instalado" en el servidor). Intenté usar un iframe para violar la misma fuente de origen de JavaScript; sin embargo, eso no funcionó. ¿Hay alguna solución alternativa de la que no tenga conocimiento?Moverse por la misma política de origen en javascript sin scripts del lado del servidor

Gracias!

+0

¿Qué navegador (s)? ¿Cómo exactamente trataste esto? Código postal? – bmargulies

+1

¡Esta pregunta es probablemente la pregunta más frecuente aquí! Una búsqueda habría planteado * numerosas * respuestas. Necesita control sobre las secuencias de comandos y las páginas en ambos dominios (si no puede editar el contenido en ambos dominios, no podrá hacerlo), y necesita utilizar un marco como http: // easyxdm .net o busque "comunicaciones de mensajes entre dominios".La especificación de HTML5 tiene un método 'postMessage', pero si confía únicamente en esto, no funcionará en la mayoría de los navegadores, por lo que tendría que recurrir a un método de" pirateo "anterior: ¿por qué no dejar que un framework tome cuidado de esto para ti? – Graza

+0

[JSON-P] (http://www.insideria.com/2009/03/what-in-the-heck-is-jsonp-and.html) es la solución más simple, y la única (AFAIK) que no requiere complementos de navegador (como Flash). Esto requiere la cooperación de cualquiera que ejecute el sitio de origen diferente. – Quentin

Respuesta

28

Como se mencionó David Dorward, JSON-P es el más simple y rápido; sin embargo, hay otro truco, específicamente el uso de dos iframes.

Dos solucionan este problema sin utilizar JSONP, puede hacer lo siguiente. Esta técnica asume que tienes algún tipo de acceso de desarrollo a la página principal.

Hay tres páginas en dos dominios/sitios.

  1. página padre
  2. página de contenido
  3. página de la comunicación entre dominios (también conocido como "xdcomm")

Páginas de las páginas de los padres y xdcomm están alojados en el mismo dominio, la página de contenido es alojado en cualquier otro dominio. La página de contenido está incrustada como un iframe en la página principal y la página xdcomm está incrustada como un iframe oculto en la página de contenido.

enter image description here

La página xdcomm contiene un script muy simple que detecta parámetros GET en la cadena de consulta, análisis sintáctico de esa cadena de method y args variables (donde args es un JSON cadena codificada), y luego ejecuta el método especificado con los argumentos especificados en la página principal. Un ejemplo puede ser seen here (ver fuente).

Aunque la misma política de JavaScript de JavaScript restringe el código en un dominio al acceder al de otro, no importa si los dominios están anidados entre sí (dominio A, anidado dentro del dominio B, anidado dentro del dominio A).

Por lo tanto, en pocas palabras, la página de contenido envía mensajes a la página principal a través de la página xdcomm cambiando el origen del iframe a algo como http://domaina.com/xdcomm.html?src=foo&args=[1,2,3,4]. Esto sería equivalente a ejecutar foo(1,2,3,4) en la página principal.

Además, sepa que ya hay bibliotecas que lo ayudan con esto, como easyxdm. Lo que he explicado aquí es la base de una de las técnicas que utilizan, y si bien puede no ser tan elegante, sin duda es una implementación totalmente funcional y ligera.

+0

En realidad sí, por favor dime !! :) – Parris

+0

De hecho voy a escribir algo bastante completo. Vuelva más tarde. –

+5

Entonces, ¿cuál es el voto negativo? –

2

¡Ojalá que no, ya que sería un agujero de seguridad! :)

Pero si ambos sitios son subdominios en el mismo dominio, tal vez document.domain puede ayudar.

+0

Entonces, si mi dominio es awesome.yahoo.com, por ejemplo, y estoy intentando acceder a bob.yahoo.com, podría establecer document.domain en yahoo. com y luego poder acceder a bob.yahoo.com? – Parris

+2

También me doy cuenta de que es un agujero de seguridad; sin embargo, esperaba que hubiera un agujero, jajaja. Si lo piensas utilizando un proxy permite una solución alternativa. No entiendo por qué se permite el uso de un proxy, mientras que el acceso directo al archivo no está permitido. También escuché que html 5 tiene algunos atributos que también permiten cosas de dominio cruzado. – Parris

+0

Un proxy no enviará cookies a los usuarios ni ningún otro dato de autenticación al sitio remoto, ya que no puede saber cuáles son. Solo puede obtener datos que el sitio podría obtener de todos modos. No puede pretender ser el usuario. Hay un trabajo continuo para desarrollar un sistema de permisos para que XHR pueda acceder a sitios remotos, el soporte del navegador actualmente es débil. – Quentin

Cuestiones relacionadas