Wednesday, July 23rd, 2008

window.name meet dojox.io.windowName

Category: Ajax, Dojo, JavaScript

We have written about using window.name as a transport and Kris Zyp has just posted about how Dojo has created a new dojox.io.windowName module.

The window.name transport is a new technique for secure cross-domain browser based data transfer, and can be utilized for creating secure mashups with untrusted sources. window.name is implemented in Dojo in the new dojox.io.windowName module, and it is very easy to make web services available through the window.name protocol. window.name works by loading a cross-domain HTML file in an iframe. The HTML file then sets its window.name to the string content that should be delivered to the requester. The requester can then retrieve the window.name value as the response. The requested resource never has access to the requester’s environment (JavaScript variables, cookies, and DOM).

You can access it in a simple way:

javascript

  1. dojox.io.windowName.send(method, args); // simple method
  2.  
  3. // deferred result
  4. var deferred = dojox.io.windowName.send("GET", {url:"http://somesite.com/resource"});
  5. deferred.addCallback(function(result){
  6.   alert("The request returned " + result);
  7. });

Kris then goes on to show how to use this with Web services and other scenarios, and explains why you may be interested:

This technique has several advantages over other cross-domain transports:

  • It is secure, JSONP is not. That is, it is as secure as other frame based secure transports like fragment identifier messaging (FIM), and Subspace. (I)Frames also have their own security issues because frames can change other frames locations, but that is quite a different security exploit, and generally far less serious.
  • It is much faster than FIM, because it doesn’t have to deal with small packet size of a fragment identifier, and it doesn’t have as many “machine gun” sound effects on IE. It is also faster than Subspace. Subspace requires two iframes and two local HTML files to be loaded to do a request. window.name only requires one iframe and one local file.
  • It is simpler and more secure than Subspace and FIM. FIM is somewhat complicated, and Subspace is very complicated. Subspace also has a number of extra restrictions and setup requirements, like declaring all of the target hosts in advance and having DNS entries for a number of different particular hosts. window.name is very simple and easy to use.
  • It does not require any plugins (like Flash) or alternate technologies (like Java).

Posted by Dion Almaer at 7:08 am
7 Comments

+++--
3.7 rating from 60 votes

7 Comments »

Comments feed TrackBack URI

I like that someone has shown yet another way that we can hack the browser environment into allowing cross-domain communication. However, these are just hacks at their core… using something that wasn’t intended for a particular purpose to “solve” a shortcoming in some other unrelated process.

Moreover, the problem with these kinds of solutions is that creating a consistent “Ajax” interface (meaning, for instance, the familiar native XHR api) becomes a lot harder and more hacky. And I believe a consistent API should be the premiere focus, not just finding yet another loophole in the browser (that may change or get plugged up later anyway).

In addition, there are some important limitations, such as the lack of ability to set request headers, nor the ability to make authenticated calls.

And this approach is dangerous because it utilizes no built in security or authentication to allow such cross-communication. Models which include the server in the decision process, such as opt-in server policies (crossdomain.xml) are IMHO a lot more robust and should be where we are focusing our energies, rather than thinking the browser alone, with a dynamic (ie, hackable) javascript engine, will be able to ever solely and securely solve this problem.

Adobe Flash has better than 99% browser acceptance, and has made great strides in their security model for cross-domain communication (though clearly there is more to be done!). So I still don’t understand why so many people want down-play solutions that rely on a plugin like flash in favor of all these other hacks? I think it’s pointless elitism to say that solution “a” is better than “b” because “a” hacks only the native browser environment and “b” uses extensions to it.

Flash and their security model were built with specific and intentional support for cross-domain communication, in a secure fashion, and I think it deserves more attention as a viable alternative.

To this end, flXHR (http://flxhr.flensed.com/) is a javascript+flash solution which implements an api-compatible drop-in replacement for the native XHR, with secure cross-domain communication support.

Comment by shadedecho — July 23, 2008

@shadedecho: I certainly agree that we want native support, as matter as fact I am on the W3C working group for cross-site access control (for XHR), and even have other posts on Ajaxian about the need for such. However, I am certainly not willing to just give up on secure mashups in the meantime. We will be dealing with legacy browsers for years to come, a idealistic desire is not going to remove that reality of our situation and the need for techniques for securely accessing data.

Your comment about lack of opt-in is incorrect, window.name does require opt-in from the server, the server must respond by setting the window.name property, this is how it signals authorization. Additionally, this protocol actually opens up the door for some very powerful UI based authorization approaches due the frame sandboxing, that can make cross-site authorization more interactive and easier to build than XHR where authorization must be negotiated using techniques similar to OAuth (although OAuth can’t be done with cross-site XHR).

We will be doing some more posts on using technique with authorization and meta-data transfers (substitute for headers). I will also be doing a post about how to use window.name with the XHR API, a consistent API is certainly one of the goals as well, this post was simply introducing the technique.

Comment by kriszyp — July 23, 2008

Also to be clear, Ajaxian has _not_ posted about using window.name as a transport before. The previous posts that are linked here discuss using it for session variables and for caching, respectively. Using it as a transport is new, as far as I can tell.

Comment by kriszyp — July 23, 2008

The name “dojox.io.windowName” is non-intuitive and only accessible to people who understand the hack.

Comment by Jordan1 — July 23, 2008

@Jordan1: This technique is only available to web services that provide resources with the window.name protocol, so to not give it a name that identifies the transport technique so you can use it with compatible services in the name would only be misleading.

Comment by kriszyp — July 24, 2008

Cool idea guys, you just solved a pressing problem. I snooped your implementation and implemented it in GWT, see here: http://timepedia.blogspot.com/2008/07/cross-domain-formpanel-submissions-in.html

I adopted your URL convention (windowname=true) for interoperability purposes. It would be nice if, like JSONP, this convention or something like it gets standardized.

-Ray

Comment by cromwellian — July 24, 2008

I ported this to jQuery as a plugin that hijacks the built-in ajax function when needed. Also changed the code from listening to onload to a timer that checks the state.

Comment by friedcell — September 30, 2008

Leave a comment

You must be logged in to post a comment.