¿Cómo comunicarse entre marcos?

Question

estoy manteniendo una aplicación que va algo así como esto:

Hay una página A con un cuadro que muestra la página B. Ahora la página B es parte de un producto completamente diferente en un dominio independiente.

Ahora, quieren que cuando se hace clic en una opción en B, la página WHOLE se redirige a otra página en A. El problema es que la URL de A es algo así como www.client.A.com/Order/Details/123, y cuando hacemos clic en debe redirigir a algo como www.client.A.com/Order/Edit/123 pero B no sabe nada de A. No sabe qué orden # está actualmente seleccionado o algo sobre A. La página A que tiene el marco B lo sabe.

Por ahora mi solución ha sido simplemente redirigir a los AllOrders así que algo como client.MyCompany/Órdenes

pero ya que B no sabe qué client está llamando (es una aplicación multi-usuario), lo lo agregaré en el webconfig. (por lo que cada cliente tiene su propia configuración web con un valor diferente).

¡No encuentro esta solución óptima, pero no puedo pensar en otra cosa! Ya traté de poner la url necesaria en la página A en una Div oculta (ya que A conoce toda la información) y luego intenté leer todo el DOM de la página desde B para encontrarla ... desafortunadamente solo puedo acceder a DOM de Frame B ... (Lo intenté con jquery).

Sé que los marcos son malvados, pero así es como está escrito ... ¿alguna idea?

Gracias!

Answer 1

Si la página primaria A y la página B de iframe están en dominios diferentes, no podrá acceder a métodos o campos a través de la propiedad primaria de B, ni la secuencia de comandos en A podrá acceder al contenido de B, ni tampoco poder compartir variables globales entre A y B. Este límite colocado entre la página A y la página B es una parte clave del modelo de seguridad del navegador. Es lo que evita que evil.com envuelva su página web de banco en línea y robe la información de su cuenta con solo leer las variables internas del javascript de la página web del banco.

Si tiene el lujo de requerir la última generación de navegadores, puede utilizar la técnica de mensaje posterior mencionada en una de las otras respuestas aquí. Si necesita admitir navegadores más antiguos, es posible que pueda pasar pequeñas cantidades de información usando técnicas de scripting de cliente entre dominios en el navegador. Un ejemplo de esto es usar iframes para comunicar información entre la página externa A y la página interna B. No es fácil y hay muchos pasos involucrados, pero se puede hacer. Escribí un article hace un rato.

No podrá supervisar los clics en el iframe de B desde la página principal A. Esto infringe las políticas de seguridad del navegador en varios niveles. (Haga clic en secuestro, para uno) No podrá ver cuándo cambia la URL de B: A puede escribir en la propiedad iframe.src para cambiar la URL, pero una vez que el iframe.src apunta a un dominio diferente al dominio de A, A ya no puede leer la propiedad iframe.src.

Si A y B están en diferentes subdominios del mismo dominio raíz, puede tener la oportunidad de "bajar" el dominio a una raíz común. Por ejemplo, si la página externa A está alojada en el subdominio A.foo.bar.com, y B está alojada en el subdominio foo.bar.com, entonces puede bajar el dominio en la página A a foo.bar.com (asignando window.domain = "foo.bar.com" en el guión de A). La página A se comportará entonces como un par de la página B y los dos podrán acceder a los datos de los demás según sea necesario, incluso aunque A esté técnicamente atendido desde un dominio diferente de B. También escribí un artículo en domain lowering.

La reducción de dominio solo puede despegar subdominios más internos para operar en el contexto de un dominio raíz. No puede cambiar A.foo.bar.com a abc.com.

También existe un pequeño riesgo en la reducción de dominios a un dominio raíz común. Cuando opera su página en su propio subdominio, su html y script se segregan de los otros subdominios fuera del dominio raíz común. Si un servidor en uno de los otros subdominios se ve comprometido, realmente no afecta su página html.

Si baja el dominio de su página al dominio raíz común, está exponiendo sus aspectos internos al script que se ejecuta en el dominio raíz común y al script de otros subdominios que también ha reducido su dominio a la raíz común. Si un servidor en uno de los otros subdominios se ve comprometido, tendrá acceso a las partes internas de su script y, por lo tanto, puede haber comprometido su subdominio también.

Answer 2

Si desea comunicarse entre bastidores en javascript que puede utilizar 'padre':

Si marco de A tiene un valor variable, por ejemplo:

var orderNo = 2; 

Para trama B para leerlo se referiría a

var frameA_orderNo = parent.frames[0].orderNo; 

(suponiendo que la trama a es la primera trama declarado)

De modo que puede configurar variables globales dentro de cada cuadro que el otro marco pueda leer y, por lo tanto, puede obtener el orden # en javascript antiguo (nunca lo intenté en jquery).

Marcos deslumbrantes: nunca pensé que volvería a pensar en ellos.

Answer 3

en caso de que la página & marco no esté en el mismo dominio, tendrá que usar postmessage ya que la política del mismo dominio prohíbe la comunicación javascript normal entre páginas/marcos de dominios diferentes por cuestiones de seguridad.

postmessage es parte de html5 y works in all modern browsers (including IE8). si necesita soporte para navegadores más antiguos (específicamente IE6/7), puede usar el jQuery postmessage plugin (que se reduce de forma transparente a un buen truco de etiqueta hash para navegadores más antiguos).

y como nota al margen: no estoy seguro de si los marcos son malos, hay algunos problemas (usabilidad, SEO, ...) relacionados con ellos, pero hice un poco de investigación y creo que most of these can be tackled.