attribute - title html español
¿Cómo comunicarse entre marcos? (3)
Estoy manteniendo una aplicación que se parece a esto:
Hay una página A con un marco que muestra la página B. Ahora la página B es parte de un producto completamente diferente en un dominio separado.
Ahora, quieren que cuando se haga clic en una opción en B, la página ENTERA se redirija 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, debe redirigirse a algo como www.client.A.com/Order/Edit/123 pero B no sabe nada acerca de A. No sabe qué número de pedido está actualmente seleccionado o nada acerca de A. La página A que tiene el marco B lo sabe.
Por ahora, mi solución ha sido simplemente redirigir a AllOrders para que sea algo así como cliente.MyCompany / Orders
pero como B no sabe a qué client lo llama (es una aplicación multiusuario), lo agregaré en el webconfig. (para que cada cliente tenga su propio webconfig con un valor diferente).
¡No encuentro esta solución óptima pero no puedo pensar en otra cosa! Ya intenté poner la url necesaria en la página A en una Div oculta (ya que A sabe toda la información) y luego trato de leer el DOM completo de la página de B para encontrarla ... desafortunadamente, solo puedo acceder a DOM de Frame B ... (Lo intenté con jquery).
Sé que los marcos son malos, pero así es como están escritos ... ¿alguna idea?
¡Gracias!
En caso de que la página y el marco no estén en el mismo dominio, tendrá que usar el postmessage ya que la política del mismo dominio prohíbe la comunicación javascript normal entre páginas / marcos de diferentes dominios debido a problemas de seguridad.
postmessage es parte de html5 y funciona en todos los navegadores modernos (incluido IE8) . Si necesita soporte para navegadores más antiguos (específicamente IE6 / 7), puede usar el complemento jQuery postmessage (que de forma transparente recurre a algunos trucos de etiquetas hash para navegadores más antiguos).
y como una nota al margen: no estoy seguro si los marcos son malos, hay algunos problemas (usabilidad, SEO, ...) relacionados con ellos, pero hice algunas investigaciones y creo que la mayoría de estos pueden abordarse .
Si desea comunicarse entre marcos en javascript, puede usar ''padre'':
Si el cuadro A tiene un valor variable, por ejemplo:
var orderNo = 2;
Para el fotograma B leerlo se referiría a
var frameA_orderNo = parent.frames[0].orderNo;
(asumiendo que el cuadro A es el primer cuadro declarado)
Por lo tanto, puede configurar variables globales dentro de cada marco que el otro marco pueda leer y, por lo tanto, puede obtener el pedido # en el javascript antiguo (nunca lo intentó en jQuery).
Wow frames - nunca pensé que volvería a pensar en ellos.
Si la página principal A y la página iframe B están en diferentes dominios, no podrá acceder a los métodos o campos a través de la propiedad principal de B, ni el script en A podrá acceder al contenido de B, ni podrá 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 la página web de su banco en línea y le robe la información de su cuenta simplemente leyendo las variables internas de javascript de la página web del banco.
Si tiene el lujo de requerir la última generación de navegadores, puede usar la técnica de postmensaje 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 utilizando técnicas de scripts de clientes de dominios cruzados en el navegador. Un ejemplo de esto es usar iframes para comunicar información entre la página exterior A y la página interna B. No es fácil y hay muchos pasos involucrados, pero se puede hacer. Escribí un article sobre esto hace un rato.
No podrá monitorear los clics en el iframe de B desde la página principal A. Eso es una violación de las políticas de seguridad del navegador en múltiples niveles. (Haga clic en el secuestro, por ejemplo) 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 se puede leer la propiedad iframe.src.
Si A y B están en diferentes subdominios del mismo dominio raíz, es posible que tenga 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, puede bajar el dominio de la página A a foo.bar.com (asignando window.domain = "foo.bar.com" en el script de A). La página A se comportará como un par de la página B y los dos podrán acceder a los datos de la otra persona según sea necesario, incluso aunque técnicamente se sirva A desde un dominio diferente al de B. También escribí un artículo sobre la reducción de dominios .
La reducción de dominios solo puede despegar de los subdominios más internos para operar en el contexto de un dominio raíz. No puedes cambiar A.foo.bar.com por abc.com.
También existe un ligero riesgo al reducir los dominios a un dominio raíz común. Cuando opera su página en su propio subdominio, su html y su script se segregan de los otros subdominios del dominio raíz común. Si un servidor en uno de los otros subdominios está 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 partes internas a las secuencias de comandos que se ejecutan en el dominio raíz común y a las secuencias de comandos de otros subdominios que también han bajado su dominio a la raíz común. Si un servidor en uno de los otros subdominios está comprometido, tendrá acceso a las partes internas de su script y, por lo tanto, puede haber comprometido su subdominio también.