OSCON 2006: Cross-site Ajax
This week, Kevin Yank is reporting from OSCON 2006 in Portland, OR.
Paralyzed by indecision (at any given time at OSCON, there are literally three different sessions I would consider “must-see” going on), I went to Plaxo developer Joseph Smarr’s Cross-site Ajax: Challenges and Techniques for Building Rich Web 2.0 Mashups, mainly because I am giving a talk on the same subject at Web Directions in September. Slides will be available on the Plaxo blog.
The story so far…
Another option is to use a Flash movie to act as the proxy. Flash has a similar same-origin policy about the requests it makes, but that policy can be suppressed if the destination service provides a
crossdomain.xml file on its domain. If Flash sees this file, and it contains a listing for the domain wanting to make the request, the cross-domain request is allowed. Of course, Flash is a proprietary, non-standards-based technology, which may not be an option for you.
A more intricate solution, called JSON-P, dynamically adds a
script element to the page in order to make the request.
<script> tags aren’t subject to the same-origin policy, so the
src attribute can point to another domain and the request will go through without complaint.
Problems with JSON-P as it currently exists include a lack of error handling, the requirement that your request be made via HTTP GET, and the possibility that the service might return malicious code that could execute within your application (for example, stealing security-sensitive cookie values).
Plaxo wanted to build a system that would allow you to pick email addresses out of your Gmail address book and have them inserted into a text field on a third party site, simply by clicking a button on that 3rd party site (and providing your Gmail login credentials the first time). That would require that 3rd party site to have cross-domain access to Gmail, and none of the above solutions would do the trick.
The provider of a service such as Plaxo’s address book selector provides an HTML file that must be added to any site that consumes the service. This file provides the callback mechanism for the service to return data to the requesting site.
When the service is invoked (e.g. the browser opens the address book selector from Plaxo in a pop-up window), and the user finishes interacting with it (e.g. the user selects one or more contacts and clicks “OK”), the service’s pop-up window loads the callback HTML file from the requesting site into an
iframe. The callback HTML file, in turn, contains a
Where to from here?
If we think about the future now, maybe we can get a platform that will not require us to “break into our own house” to build mashups. Smarr believes (and I wholeheartedly agree) that developers should be discussing these issues now to shape the platforms of the future so that they support the needs of mashup developers without compromising the strict—yet invisible to the user—security model that is in place today.
There are a number of proposed solutions already on the table. One possibility would be to set up a standard way to define trust relationships between sites. Flash does it with
Other ideas on the table include proposed browser enhancements such as Chris Holland’s
ContextAgnosticXmlHttpRequest, which unlike the current
XMLHttpRequest object would permit cross-domain requests, but would not send any cookie or HTTP authentication headers, and might only connect to servers that send the
X-Allow-Foreign-Hosts header in their HTTP responses. Douglas Crockford’s proposed
JSONRequest would work under similar restrictions, but would be specific to JSON-formatted services. But the restrictions proposed with these solutions might be going too far.
Whichever solution you prefer, the real message is that the future of AJAX in general and mashups specifically is wide open, and you need to get involved in the process of defining its evolution. There are no easy answers yet, and these problems aren’t going away anytime soon. But perhaps most importantly, the browser developers are listening more than ever, and we need to tell them what we, as developers, want.