my 2 cents

Cross site communication in the browser using the XHTTPRequest Object is prohibited by the Same Domain Policy. With HTML 5 this restriction is relaxed within the so called workers.

As of now, normally the browser can only communicate with the domain the document being displayed comes from. As always, most restrictions can be circumvented somehow. Quite a while now, the de facto standard approach for cross-site communication in the wild is JSONP.

In short: A javascript located at the foreign domain is inserted in background. Via the GET url parameters the data of the request is send. The script returned by the foreign server contains code which gets directly executed at include time of this script, e.g: callback({jsondata});

It is widely accepted that JSONP should be rated highly insecure for multiple reasons:
- Including a script of a foreign domain is a build in XSS attack.
- All parameters send to the foreign domain are part of the standard access logs of the foreign web servers.
- …

A new idea for secure cross site communication has come up a year ago utilizes the fact, that the name property of browser windows/frames remains unchanged when a window/frame loads a new document even from a foreign domain. With this, it is possible to create a transport by inserting a hidden iframe which switches its document between the origin- and foreign domain.

This approach has the major advantage, that the data returned by the foreign domain is encoded as a string and could be evaluated in a safely. Moreover the request could be done via POST’s which solves EOI issues with server logs.

While I was aware of this new technique, I never had the need to do cross site request from the browser. In general my approach is to proxy data from foreign domains via the server as this gives a better control. However for a Tine 2.0 related customer project I had the requirement to do cross site request from a website to a Tine 2.0 installation directly from the browser.

Unfortunately I didn’t find any extjs/ext-core implementation of the window.name technique. Moreover I realized, that the implementation of other libraries always POST their request using form submits. But doing all request via form Submits would require an additional API for Tine 2.0 as the standard JSON API talks JSONRPC.

So what I needed was a XHTTPRequest/AJAX solution to be able to utilize the standard Tine 2.0 API’s. For this I created a windowNameConnection Proxy which based on ext-core does AJAX requests to the foreign domain. This sequence diagram visualizes it’s simple workings:

You can find the latest version of the implementation here. The usage of this connection class is straight forward as it works like a normal extjs connection:

var connection = new Ext.ux.data.windowNameConnection({
    // this url is autodetected if windowNameConnection is loaded
    // from the foreign domain
    proxyUrl: https://foreign.domain/windowNameConnection.html
});

connection.request({
    url: https://foregin.domain/apiurl,
    header: {...}
    params: {...},
    success: someSuccessCb
});

Of course the ability to do AJAX requests is purchased by a minor performance loss compared to form posts. BUT: The windowNameProxy should only be seen as a fallback for Browsers which are not capable of the HTML5 workers. Users of these old browsers are obviously not keen on enhanced performance. Otherwise they would use an up to date browser.