del.icio.us direc.tor: Creating A Client-Side Web Service Broker

June 20, 2005

Initially, I had planned on using the XmlHTTPRequest object to create a client-side application that integrated various web services like Google suggest, del.icio.us, Flickr, Yahoo developer network, etc. Unfortunately, the browser security restrictions severely limit the capabilities of a client-side application, essentially eliminating any cross-domain integration services. However, single-domain services can still be implemented by using the Javascript bootloading technique.

Same-Origin Policy

The most frustrating part of creating any client-side application is the security model that applies to just about all executable objects that can be accessed by the browser. Designed the prevent cross-site scripting attacks (XSS), the same-origin policy effectively prohibits a page served from www.mydomain.org to access any document served from a different domain, via XmlHTTPRequest, IFRAME's, or similar DOM methods. Therefore, a page with a URL of http://www.mydomain.org:80/ cannot access another page that does not share the same protocol, domain, and port.

One exception to this rule is when the document.domain property is set. This exception stipulates that in an FRAME/IFRAME situation, documents served from different subdomains of the same base domain may access each other's DOM tree if both pages set their respective document.domain property to the base domain. For example, if a page blue.domainA.org/master.html contains an IFRAME of the page red.domainA.org/slave.html, then by default the two pages will not be allowed to access each other's DOM tree. However, if both pages contain an explicit Javascript command, document.domain = "domainA.org";, then access to the DOMs will be granted. What is somewhat confusing is that all pages have a valid document.domain property that is set, but is considered null by the security model until it is set explicitly. Unfortunately, XmlHTTPRequest objects are not affected by the document.domain property. XmlHTTPRequest will only fetch documents from the originating server. In fact, you have to specify a relative URL, since it completely ignores any URL's with a fully-qualified domain name.

None of these security policies apply when executing a web page served from localhost. You can use IFRAME's and XmlHTTPRequest objects to access any valid URL to your heart's content.

Using the Javascript Bootloader

You can execute arbitrary Javascript code in the security context of any web page by simply typing a javascript command into the browser's address bar:

javascript:void(document.body.style.backgroundColor='#c00')

That command can also be bookmarked by either editing a bookmark property directly or using the drag-and-drop method, thus creating a Javascript bookmarklet. As anyone who has had the displeasure of implementing third-party banner ads knows, a web page may contain a <script> reference to any valid URL, i.e. <script src="http://shoddy.advertiser.net"></script>. The Javascript bootloader uses this capability to inject foreign code — not by writing out a <script> string, but by way of DOM node creation:

// Create a new script node
var element = document.createElement('script');
// set the 'src' attribute of the element
element.setAttribute('src', 'http://johnvey.com/features/deliciousdirector/dboot.js');
// insert the new node into the current document
document.body.appendChild(element);

Once the new script node is inserted, the browser will automatically process the attached code. The complete javascript bookmarklet is as follows: