HTML5 throws a domain hissy fit

In my last post I overviewed a number of new communications features in HTML5 that in my mind will no doubt transform web applications moving forward. One of those features was Cross Document Messaging which is one of the most exciting new features I’ve found in the specification.

One of the big constraints of web applications has been allowing separate applications to talk to each other. For example let’s say you have a phone book application and you have a news feed application. If you wanted to show news for a person you selected in your phone book you couldn’t get the phone book to tell the news application which person you had selected, you would have enter the person’s name in the news application and then search: a series of manual steps as automation wasn’t possible.

Along came portal technology, followed by portal standards (JSR168 then JSR286), which enabled applications to do exactly this, share data (of course they have many other features and benefits to). Whilst a portal page can consist of applications (portlets) running off different servers, the main constraint of them sharing data is that they have to be on the same portal page i.e. you couldn’t have two applications running in separate browser windows or tabs and sharing data or passing messages between them.

Cross Document Messaging overcomes this. Essentially an application can use PostMessage to send a message:

my_iFrame.contentwindow.postmessage(‘Hi there’, ‘http://www.myapp.com/’);

NOTE: you can’t send message from a https to http (or vice versa) application.

The targeted application must implement an event listener:

window.addEventListner(“message”, msgHandler, true);

and obviously create the msgHandler function to process the message.

function msgHandler (e) {…..handling code…..}

The receiving application will be notified of the senders web address (origin) and can therefore choose to ignore the message if it is coming from an unrecognised source. It is best practice for the receiving application to maintain a “white list” trusted origins and check these before processing messages.

Even with trusted origins messages coming in as strings need to be validated as they could contain script and open themselves up to an “inject attack”. This is where the string contains script rather than data, if the script is evaluated it essentially issues a set of commands to the receiving apps server.

The two applications can be in entirely separate browser windows, hence overcoming the constraint of a portlet approach.

The concept of Origins is used by other new features such as XMLHttpRequest. As per my last post previously this API was only able to talk it’s own origin. Now it can talk to other origins, essentially allowing for content to be aggregated in the client rather than just at the server as is the case today.

This is a simple posting of a powerful capability, certainly an area web developers should consider delving deeper into.

Dharmesh Mistry is the CTO/COO of Edge IPK, a leading provider of front-end Web solutions. Within his blog, “Facing up to IT”, Dharmesh considers a number of technology issues, ranging from Web 2.0, SOA and Mobile platforms, and how these impact upon business. Having launched some of the very first online financial services in 1997, and since then delivering online solutions to over 30 FS organisations and pioneering Single Customer View (Lloyds Bank, 1989) and Multi Channel FS (Demonstrated in Tomorrow’s World in 99), Dharmesh can be considered a true veteran of both the Financial Services and Technology industries.