UX Media

We help you make more money with your website by providing customer insight through user centred design and research.

Also in this section

Cross domain scripting

Once upon a time the internet was quite a simple little place where every interaction required synchronous transaction between the client and the server. 

You entered some information in to a form, pressed a button and the page was sent to a server somewhere for processing. The results were returned to you when the page reloaded.

Life was simple: Post - get response - reload page and move forward on your merry way.

Then JJG decided to blow the whole model apart by creating a cool name for XMLRPC (AJAX).This very simple act changed the 'transactional'  nature of the web. It was no longer cool to wait for a the whole page to refresh; people expected portions of web page to load asynchronously.

This new world of website has created a bit of a headache for the security bods because accompanying this new transaction model was a 'hailstorm' of new web services; little code islands a developer can contact to get information on everything from book reviews to weather forecasts to bank statements.

The thing that troubled the security bods now was how to ensure the credentials of the web sites connecting to a web service.

The answer was to enforce a sand box in the browser to prevent websites outside of the domain to connect to the web service. Very cool, except most web developers want to use web services from Amazon etc.

One easy way to get round this was to use Flash as a conduit for the AJAX request. However, Adobe have been very busy updating the Flash Plugin to enforce a tighter security model. This process started by requiring the presences of a crossdomain.xml file on the web service root.

At first, all you were required to do was include the following lines of code:

<cross-domain-policy>
    <allow-access-from domain="*" secure="true|false"> 
</cross-domain-policy>

So, OK, you can provide a domain name or IP address in the domain attribute to only allow access from a specific domain, for closed access.

With the introduction of Flash Player 9, Adobe have started to tighten the security model. Now you are required to specify accepted request headers:

<cross-domain-policy>
    <allow-access-from domain="*" secure="true|false" />
    <allow-http-request-headers-from domain="*" headers="*" secure="true|false" />
</cross-domain-policy>

And with the launch of Flash Player 10 the security is going to be even tighter. The culmination of all these changes is that a lot of Flash applications have the potential to stop working if the crossdomain.xml file hasn't been updated in line with the changes to Flash's security model.

Download a copy of our crossdomain.xml which works with Flash Player 9. We'll update it when Flash player 10 is out of beta.

Case studies

rias-logo.jpg

Creating a highly usable information architecture and online insurance purchasing process for the over 50s.

NHS Direct

UX Media are pleased to provide solution architecture and user experience research to NHS Direct's primary health information resource.

B&Q

Leading DIY brand, B&Q, commissioned UX Media to provide user experience services for both their recent website redesign and a review of the online checkout process.