En la Web actual es común el intercambio de información entre documentos pertenecientes o no al mismo dominio, no obstante es un problema no muy sencillo de solucionar. Un ejemplo común es cuando se tiene un anuncio publicitario contenido en un iframe alojado en un servidor externo, en el cual se necesita enviar valores relacionados con el contenido de la pagina principal, esto con la finalidad de mostrar un anuncio adecuado.
Para automatizar este proceso recurrimos a JavaScript, y lo más sencillo es que el iframe lea de alguna manera la etiqueta meta keywords de la página principal o que esta misma proporcione dicha información; sin embargo, el acceso al DOM desde cualquiera de las partes no está permitido por el navegador, esto debido principalmente a la política del mismo origen –una medida importante de seguridad presente en los navegadores modernos– que admite la comunicación sin restricciones de scripts en documentos del mismo sitio, no siendo así entre aquellos que son diferentes.
Ante esta problemática surgieron algunos mecanismos como Cross-Frame Messaging; una solución que carece de naturalidad, poco elegante y que requiere hacer malabares.
[nota:7e3558eab3] En los siguientes ejemplos se han utilizado dominios locales (revisar el apéndice) así como la ultima versión de Google Chrome. [/nota:7e3558eab3]
Cross-document messaging: enviando y recibiendo mensajes
El envío de un mensaje es relativamente sencillo, no hace falta más que utilizar el método postMessage de un objeto window referenciado, ya sea de la propiedad contentWindow de un iframe, el objeto devuelto dewindow.open, o un nombre/indice en window.frames.
Código :
window.postMessage( Mensaje, Origen );
El primer parámetro es el mensaje que va a ser enviado. Éste puede ser una cadena de texto, un objeto, un array, etc.
El segundo parámetro es el dominio de la ventana objetivo, es decir, la ventana que va a recibir el mensaje. Si no se desea especificar un origen en concreto puede utilizarse un asterisco como comodín, sin embargo esto no es nada recomendable ya que deja enormes agujeros de seguridad. Por otra parte si el origen es el mismo que el del emisor puede utilizarse simplemente una barra diagonal: "/" (lamentablemente Google Chrome no soporta este último).
También puede añadirse un tercer parámetro, el cual debe ser un objeto MessagePort, pero esto será tratado mas adelante.
Enviar un mensaje
http://emisor.com/emisor.html
Código :
... ...
Al dar click al botón se enviará un mensaje con el contenido: "Hola, ¿como estas?", al iframe alojado en receptor.com; sin embargo nuestro ejemplo no está completo con sólo enviar el mensaje, también es necesario recibirlo, pero antes de continuar es importante conocer los atributos del evento message que será disparado en receptor.com cuando se reciba un mensaje.
Atributos del evento message
El evento message está compuesto por cinco atributos que sólo pueden ser leídos, que básicamente significa que es imposible alterar el valor de cualquiera de ellos.
- evento.data: contiene la información del mensaje enviado por el emisor.
- evento.origin: devuelve una cadena de texto conteniendo el origen del emisor. Ej. http://emisor.com
- evento.lastEventId: una cadena con el identificador único del actual evento de message.
- evento.source: es una referencia al objeto window de quien envía el mensaje.
- evento.ports: un array conteniendo un objeto de MessagePort enviado junto al mensaje.
Recibir un mensaje
http://receptor.com/receptor.html
Código :
…Aún no he recibido nada. :(…
El funcionamiento del ejemplo anterior es simple: se comienza a escuchar al evento message; cuando un mensaje es detectado, se dispara el método recibirMensaje que simplemente verifica que el origen sea el esperado y después se coloca el texto recibido dentro del elemento #mensaje.
[nota:7e3558eab3] Si intentan mandar a la consola – console.log(evento) – la información del objeto evento, se darán cuenta que al final les aparece un error. Esto se debe a lo que mencioné al principio, el receptor sólo tiene acceso a la información que explícitamente es enviada, y al colocarlo en la consola está siempre y tratará de imprimir todo el árbol del DOM.[/nota:7e3558eab3]
Como pueden ver es igual de sencillo recibir un mensaje, pero deben tener siempre presente que se tiene que verificar que en efecto, el origen sea el esperado, incluso el tipo de dato que se espera: una cadena de texto, un número, un objeto, etc. Además de que es muy importante que se controle el número de mensajes que pueden ser recibidos por minuto, de lo contrario dejarían la puerta abierta a un posible ataque de denegación de servicio.
Ahora bien, por qué no extender el ejemplo haciendo que nuestro receptor sea capaz de ser emisor también, y viceversa:
http://emisor.com/emisor.html
Código :
...Esperando contestación......
http://receptor.com/receptor.html
Código :
…Aún no he recibido nada. :(...
Ver ejemplo funcionando en el navegador
Ventana externa
MessageChannel y MessagePort
Hasta ahora sólo hemos visto la primera mitad que compone la especificación de HTML5 web messaging; sin embargo esta también nos provee de un objeto llamado MessageChannel, el cual permite el funcionamiento de dos piezas de código independendientes (ej. corriendo en diferentes contextos de navegación) comunicarse directamente. Por ejemplo: tenemos dos iframes contenidos en un documento: por simple deducción concluimos que están en el contexto de navegación del documento principal; por otra parte, estos iframes entre sí no están en el mismo contexto; a pesar de que están juntos; uno no sabe de la existencia del otro.
Otro ejemplo: considera una situación en la cual una red social tiene incrustado un iframe de una libreta de direcciones, y otro iframe que contiene un juego en línea. El juego necesita las direcciones electrónicas de los amigos del usuario, para esto se necesita la información de la libreta de direcciones. Es aquí cuandoMessageChannel hace su aparición para hacer este proceso posible, en este caso la red social actuaría como mediador en la comunicación entre ambos iframes.
[nota:7e3558eab3] Lamentablemente Firefox todavía no soporta MessageChannel.[/nota:7e3558eab3]
Componentes de MessageChannel
El objeto MessageChannel está compuesto por dos puertos (port1 y por2) que no son otra cosa sino objetos de MessagePort, y estos a su vez contienen tres métodos:
- puerto.postMessage( mensaje ): envía mensajes a través del puerto en cuestión.
- puerto.start(): comienza el envío de mensajes a través del puerto.
- puerto.stop(): detiene el envío de mensajes a través del puerto.
MessagePort también contiene el evento onmessage, que puede ser utilizado en lugar de agregar un addEventListener.
Ejemplo
Con la finalidad de explicar mejor cómo trabajan MessageChannel y MessagePort, en este ejemplo nos basaremos en el escenario de la red social descrito anteriormente.
[nota:7e3558eab3] Por cuestiones de infraestructura se utilizara un mismo origen; sin embargo la estructura es básicamente la misma para orígenes externos.[/nota:7e3558eab3]
En primera instancia tenemos la página del juego. Lo primero que haremos es definir una función que se ejecutará cuando la estructura de nuestro documento esté completamente cargada. El objetivo primordial de esta función será el indicar a nuestro documento principal – la red social – que ya está listo para empezar a recibir correos. Para conseguir esto se crea un nuevo objeto MessageChannel, del cual su segundo puerto será enviado en un mensaje al documento principal. Después iniciamos nuestro primer puerto para procesar los mensajes que serán recibidos.
http://red-social.com/juego.html
Código :
…
La red social actuará como proxy: será quien enlace el juego con la agenda. Una vez que se reciba el mensaje de parte de la página del juego será enviado un mensaje a la agenda contiendo el puerto para comunicarse con el juego.
http://red-social.com/redsocial.html
Código :
… ...
En la agenda tenemos un simple formulario con una entrada de texto, en el cual serán ingresadas las direcciones electrónicas.
http://red-social.com/agenda.html
Código :
…...
[nota:7e3558eab3] Por cuestiones de legibilidad y simpleza se omitieron todas las validaciones que deben hacerse; validar el origen, el tipo de datos, etc.[/nota:7e3558eab3]
Ver el ejemplo funcionando en el navegador.
Conclusión
Esta es una tecnología asombrosa que ayudará a hacer la vida mas fácil a muchos desarrolladores, no obstante habrá que esperar un tiempo más, ya que los navegadores principales solo han implementado parcialmenteHTML5 web messaging.
Referencias
http://dev.w3.org/html5/postmsg/
https://developer.mozilla.org/en/DOM/window.postMessage
http://dev.opera.com/articles/view/window-postmessage-messagechannel/
Apéndice
Para simular distintos dominios se agregan entradas al archivo hosts de los dominios deseados, por ejemplo: emisor.com, receptor.com y red-social.com. En Ubuntu y Mac este archivo se encuentra en "/etc/hosts" y"system32\drivers\etc\hosts" en Windows. Se echa a andar un servidor web, como Nginx (aunque vale con cualquier otro como Lighttpd, Cherokee o el tradicional Apache) con los dominios apuntando a una misma carpeta, sin otro motivo más que de comodidad, ya que se tienen los archivos juntos.
Archivo hosts
Código :
127.0.0.1 emisor.com 127.0.0.1 receptor.com 127.0.0.1 red-social.com
Configuración ejemplo de Nginx
Código :
server {
listen 80;
# Tres dominios distintos apuntando a la misma carpeta.
server_name emisor.com alias receptor.com red-social.com;
location / {
root /home/jonasanx/public_html;
autoindex on;
}
}
0 comentarios:
Publicar un comentario