Friday, February 29th, 2008
xssinterface: cross domain access using postMessage and more
Malte Ubl has put together a library called xssinterface (somewhat scary name) that uses postMessage when available, and tries work-arounds when not, to give you cross domain JavaScript access.
How it works
For Browsers that support it, we use the postMessage() interface.
For all other browsers, we use the following mechanism:
All sites that participate in the cross domain calls must provide an html file (cookie_setter.html) that is provided by this library that enables other domains to place certain cookie under the domain of the site.
The library uses this mechanism to place cookies on the target domain that are then read and evaluated by the target page.
Pages must explicitly grant access to their domain by setting a security token cookie under a domain that is allowed to access the callbacks.
As a caller you say:
-
-
function sayHello() {
-
var caller = new XSSInterface.Caller("www.two.com","/cookie_setter.html","channel1");
-
caller.call("hello", "Hello World")
-
}
-
As the listener:
-
-
window.onload = function () {
-
window.xssListener = new XSSInterface.Listener("1234567890","channel1");
-
window.xssListener.allowDomain("www.one.com", "/cookie_setter.html");
-
window.xssListener.registerCallback("hello", function (msg) {alert(msg)} )
-
window.xssListener.startEventLoop()
-
}
-
It would be nice if the library used cross domain workers if Gears is installed.












This looks pretty cool. Could this be used to revive html-inline style Google Widgets or Facecook Apps without the security problems?
Mike
Hey, thanks for the post. Actually, I’m not sure whether this could be implemented (nicely) via Google Gears dross domain workers. I guess one could ask the cross domain worker to store a message on the local store and then have another non-cross-origin worker look for those messages.
Whats the pain with crossdomain info?
Using javascript seem to resolve the matter quite nicely..
Thanks for the hint to google gears. It is now implemented in trunk :)
I see it is sending data through the GET data it sends to cookie_setter.html.
Can it send more data in IE than the 2048 post character limit?
Tried on http://bse.blogsome.com but no l uck