Loading ...
Sorry, an error occurred while loading the content.

window.name transport

Expand Messages
  • Kris Zyp
    I have been investigating an idea for a secure cross-site transport. It seems unlikely that no one has done anything like this before, but I can t find any
    Message 1 of 1 , Jun 9, 2008
      I have been investigating an idea for a secure cross-site transport. It seems unlikely that no one has done anything like this before, but I can't find any evidence of it. But I wanted to run this by you, see if I was missing something obvious. The basic idea is this: do a request with an iframe (GET or POST) to a cross-domain target, and then the target responds with an page that sets it's window.name to the content of the resource that was requested. The requester then changes the iframe back to a page that is in same domain as the requester, and the requesting page can then retrieve the name of frame's window.name to retrieve the data from the target resource. This has several advantages:
      1. It is secure, JSONP/script tag insertion is not. That is, it is as secure as other frame based secure transports like fragment identifier messaging (FIM), and Subspace. Frames also have their security issues, with phishing and such, but that is quite a different security exploit.
      2. 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 much "machine gun" sound effects. It is also faster than Subspace. Subspace requires two iframes and two local html files to be loaded to do a request. Frame Naming only requires one iframe and one local file.
      3. 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 before hand and having DNS entries for a number of different particular hosts. window.name is very simple and easy to use.
      The main advantage of Subspace over window.name is that Subspace uses the script tag/JSONP loading technique which has pretty decent acceptance and implementation. window.name is easier for servers to implement than FIM, but it still requires a few lines of HTML and String quoting around the resource.
      Here is a demonstration of my implementation of window.name: http://sitepen.com/labs/code/secure/dojox/io/tests/windowName.html. This is based on Dojo, and by default connects to a x-domain resource served from my demo version of Persevere (I added the window.name capability to it), but you can give it any URL that will output data via the window.name format. It appears to work in all the major browsers. The idea is based Thomas Franke's new library for doing session variables with window.name, but this obviously a completely different goal. I think you could also adapt this technique for doing cross-frame messaging (emulate postMessage). Also, my apologies that the demo is slow, it is using an "unbuilt" version of Dojo. It is much faster when built.
      Anyway, does this seem like a reasonable approach to cross-site requests (while we wait for XDR and/or XHR/AC)?
    Your message has been successfully submitted and would be delivered to recipients shortly.