- Older in JavaScript/DHTML:
JavaScript heebie jeebies - Newer in JavaScript/DHTML:
javascript hijaking
Hoping to clarify:
Having a page built up of parts that come from different domains adds value and power. Having a page built up of parts from different domains adds complexity, lack of control and security hazards.
There are browser rules that determine what kind of things can be done between different domains in an attempt to balance these two factors.
Things the browser won't let you do between domains:
- use JS to get any info about other pages in the browser served from the different domains (including those in frames)
- use JS to trigger any kind of activity in the window context of a page served by another server
- XmlHttpRequest from a page in one server to a URL in another
- share cookies (depending on user settings)
Things the browser will let you do between domains
- embed on a page an image from a different server
- embed in a page a JS from another server
- embed in a page a CSS from another server
- anchor link to a page on a different server
- share cookies (depending on user settings)
As you might guess, existing third part mashups and APIs use some combination of things from the second list. Most people would consider them Ajax even though they rely on including Javascript files, image requests, etc., not on using the XmlHttpRequest.
And for anyone who read the list and is now thinking... "wait, what? I can include arbitrary executable code on my page with no restrictions (JS file) but I can't do an http request for a piece of content that I then process with any level of care I deem necessary (XmlHttpRequest)?" Yes it is crazy and I'm pretty sure the reasons are historical.
All of this leaves the fundamental problem more or less unsolved. What do you do about functionality that might add power but might erode security?
Opera has done some work on an API for passing info from one domain to the other. It involves defining a way for JS code to shove objects and event handlers into a formally shared space. By exposing only the API you want to expose (and with the ability to limit who you expose it to) it greatly reduces the security risks.
To some extent this model is already available using the double iframe hack, which relies on the fact that if a page creates an iframe whose source goes to another server, and that inner page creates an iframe whose source is back in the outermost server's domain, the innermost and outermost iframes can share data. Both pages can manipulate the URL of the innermost iframe and share information that way.
Dated: 03/16/2007