This link has been bookmarked by 143 people . It was first bookmarked on 31 Mar 2008, by Tristan Rivoallan.
-
31 Dec 17
-
14 Aug 14
-
01 Jan 14
-
16 Nov 13
-
Parent windows are accessed as “parent”, “parent.parent”, etc., or “top” for the top-level. Child windows are accessed as “window.frames[0]” or “window.frames[name]“.
-
Windows can only access each others’ internal state if they belong to the same domain.
-
Any window in the hierarchy can set (but not read) any other window’s location/URL
-
When you change the URL’s fragment identifier (the bit on the end starting with a #, e.g. http://example.com/blah#fragmentID), the page doesn’t reload.
-
- Window A changes Window B’s fragment identifier.
- Window B is polling the fragment identifier and notices the change, and updates itself according to the fragment identifier.
-
- Every time Window A wants to call Window B, it spawns a child iframe, “Window B2″ in the same domain as Window B. The URL includes the command being issued (as a CGI parameter, fragment identifier, or any other URL pattern which will be recognised by the destination script).
- When window B2 starts up, its Javascript inspects the URL, gets a handle on Window B, and updates Window B according to the URL (e.g. a CGI parameter).
- Window B2 destroys itself in a puff of self-gratified logic.
-
-
18 Dec 12
-
14 Nov 12
-
What you can do with IFrames
-
Law I: Any window in the hierarchy can get a handle to any other window in the hierarchy
-
It doesn’t matter where they live within the hierarchy or which domain they come from – with the right commands, a window can always refer to any other window
-
Law II: Windows can only access each others’ internal state if they belong to the same domain.
-
Law III: Any window in the hierarchy can set (but not read) any other window’s location/URL, even though (from Law II) browser security policies prevent different-domain iframes from accessing each other’s internal stat
-
Law IV: When you change the URL’s fragment identifier (the bit on the end starting with a #, e.g. http://example.com/blah#fragmentID), the page doesn’t reload
-
- Window A changes Window B’s fragment identifier.
- Window B is polling the fragment identifier and notices the change, and updates itself according to the fragment identifier.
-
So in this case, we create a new, short-lived, iframe for every message being passed.
-
-
05 Nov 12
XO Q"With modern browsers, you can and should be using postMessage for this purpose.
Library support is now available too. All of the following provide an interface to postMessage where it’s available, but if it’s not, fall back to the primordial techniques described in this article:
Porthole
XSSInterface
EasyXDM
jQuery PostMessage Plugin" -
24 Sep 12
-
14 Sep 12
-
09 Jul 12
-
26 Jun 12
-
17 May 12
-
03 May 12
-
20 Apr 12
-
11 Apr 12
-
03 Apr 12
-
22 Mar 12
-
08 Mar 12
-
15 Dec 11
-
06 Dec 11
-
29 Oct 11
-
27 Oct 11
-
24 Sep 11
Khánh TrầnCross-Domain Communication with IFrames http://t.co/20LPAKWZ
-
15 Aug 11
-
08 Jun 11
-
30 Apr 11
-
15 Apr 11
-
30 Mar 11
-
22 Mar 11
-
09 Mar 11
-
12 Jan 11
-
10 Jan 11
-
27 Dec 10
-
23 Dec 10
-
19 Dec 10
-
21 Nov 10
-
05 Nov 10
-
03 Nov 10
-
26 Oct 10
-
20 Oct 10
-
07 Oct 10
-
05 Oct 10
-
01 Oct 10
-
09 Sep 10
-
03 Sep 10
-
02 Sep 10
-
23 Aug 10
-
14 Aug 10
10base TomThis article explains iframe-to-iframe communication, when the iframes come from different domains. That you can do this effectively is only now becoming apparent to the community, and is now used in production by Google, Facebook, and others, and has powerful implications for the future of Ajax, mashups, and widgets/gadgets. I’ve been investigating the technique and working some demos, introduced in the article.
-
12 Aug 10
-
So it’s not easy to mash content from multiple sources, when everything must be squeezed through the originating web server.
-
-
28 Jul 10
-
21 Jul 10
-
19 Jul 10
-
13 Jul 10
-
This article explains iframe-to-iframe communication, when the iframes come from different domains. That you can do this effectively is only now becoming apparent to the community, and is now used in production by Google, Facebook, and others, and has powerful implications for the future of Ajax, mashups, and widgets/gadgets. I’ve been investigating the technique and working some demos, introduced in the article.
-
22 Jun 10
-
12 May 10
-
01 May 10
Fictrix .This article explains iframe-to-iframe communication, when the iframes come from different domains.
security iframes cross-domain magnolia import web development delicious import
-
23 Apr 10
-
14 Apr 10
-
11 Apr 10
-
07 Apr 10
-
changing a document’s “href” property causes it to reload, but if you only change the fragment identifier, it doesn’t. You can use this knowledge to change the URL symbolically – in a manner which allows a script to inspect it and make use of it – without causing any noticeable change to the page content.
-
both Window A and Window B have one common piece of state – the URL – and the fact that we can change the URL unintrusively by manipulating only the fragment identifier.
-
Polling slows down the whole application; (b) Polling always involves some lag time (and there’s always a trade-off a and b – the faster the response, the more cycles you application uses up); (c) The URL visibly changes (assuming you want to manipulate the top-level window).
-
Window A wants to call Window B, it spawns a child iframe, “Window B2″ in the same domain as Window B. The URL includes the command being issued (as a CGI parameter, fragment identifier, or any other URL pattern which will be recognised by the destination script).
-
- When window B2 starts up, its Javascript inspects the URL, gets a handle on Window B, and updates Window B according to the URL (e.g. a CGI parameter).
- Window B2 destroys itself in a puff of self-gratified logic.
-
we create a new, short-lived, iframe for every message being passed. Because the iframe comes from the same domain as the window we’re trying to update, it’s allowed to change the window’s internal state
-
Window B2 is sometimes called a proxy because it accepts commands from Window A and passes them to Window B.
-
the downside is that you must create a new iframe for every call, which requires a trip to the server. However, with caching in place, that could be avoided, since everything that must happen will happen inside the browser. So it would simply be the processing expense of creating and deleting an iframe element
-
involves setting up a subdomain and updating its DNS to point to a third-party website.
-
window resize events are used to cause a more direct trigger.
-
The best known technique for calls from the browser to an third-party server is On-Demand Javascript, aka Javascript APIs aka JSON/JSONP.
-
It works by spawning a new script element programmatically, an element pointing to an external Javascript URL. Since there’s no restriction on third-party Javascript running, the browser will faithfully fetch and execute the script, and so the script will typically be written to “return” by updating variable and/or calling an event handler.
-
There are two major security issues with On-Demand Javascript. Firstly, you have to trust the API provider (e.g. Yahoo!) a lot because you are letting them run a script on your own web page. And there’s no way to sanitise it, due to the script tag mechanism involved.
-
We’ll increasingly have OAuth-style APIs where users will tell Site X that Site Y is allowed to read its data.
-
Note that all Facebook ever exposes is a standard web service that relies on the user being logged into Facebook – there’s no Javascript involved. The user must be logged in and must have given permission for the application to access its Facebook details. Effectively, the user is allowing a particular website URL to make Facebook calls, since the application developer must register the URL. If you look back at the iframe algorithms I described earlier, you’ll see that it’s straightforward for Facebook to ensure that only this application (and any other application the user trusts) can access the data. The Facebook.com iframe (whose behaviour is controlled by IFrame and can’t be tampered) simply has to inspect the URL of the parent window and pass it to the server as part of the XHR call. The server can then check that the logged-in user has authorised this application, using the URL to identify it.
-
-
27 Mar 10
-
20 Mar 10
-
14 Mar 10
-
16 Feb 10
-
15 Feb 10
-
13 Feb 10
-
04 Jan 10
-
09 Dec 09
-
02 Dec 09
-
08 Nov 09
-
Any window in the hierarchy can set (but not read) any other window’s location/URL
-
how strange that a child window is allowed to alter its parent’s (or uncle’s, sibling’s, etc.) URLs!
-
-
03 Nov 09
-
13 Oct 09
-
29 Sep 09
-
28 Sep 09
-
25 Aug 09
Xavier BadosaThis article explains iframe-to-iframe communication, when the iframes come from different domains. That you can do this effectively is only now becoming apparent to the community, and is now used in production by Google, Facebook, and others, and has pow
javascript iframe cross-domain ajax security xss hacks crossdomain resize gadgets widgets
-
20 Jun 09
-
16 Mar 09
-
01 Mar 09
-
16 Feb 09
-
13 Feb 09
-
11 Feb 09
-
09 Feb 09
-
29 Jan 09
-
21 Jan 09
-
08 Oct 08
-
26 Jun 08
-
26 May 08
-
13 Apr 08
-
09 Apr 08
-
05 Apr 08
-
31 Mar 08
Tristan RivoallanThis article explains iframe-to-iframe communication, when the iframes come from different domains. That you can do this effectively is a relatively recent discovery AFAICT, already used in production by Google, Facebook, and others, and has powerful implications for the future of Ajax, mashups, and widgets/gadgets. I’ve been investigating the technique and working some demos, introduced in the article.
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.