If you have a page and an iframe in it, and the iframe viewport height changes, browser adds scrollbars to the iframe.
Sometimes it’s ok, but when you need your iframe to “expand” automatically on the host page, you have to change the iframe object height style property. And it’s dead easy when both iframe and the host page are from same origin – you just talk to parent window from the iframe and make it set the object height.
So the proper approach would be to use CDM with a fallback to location.hash – newer browsers (IE8+ and current Firefox, Opera, Safari and Chrome) support postMessage, older versions will fall back to setting parent page location.hash property and on the parent page – interval polling for changes.
Here’s a basic working sample implementing this approach and here’s the code for it:
Please note that in this sample no origin check is done for the message on the parent page and the message is sent from the client page to * origin. This might be a serious security breach since the parent page will process a message send from any page, but in my case it’s OK because the worst thing that can happen – the iframe height will change. Please don’t use this as a universal solution for cross-iframe communication – there’re plenty of plugins and libraries that do it properly. I built it this way just to fit my exact needs – i.e. change height of the iframe object on a parent page.
This X-FRAME-OPTIONS HTTP header invented by Microsoft for IE8 provides an easy way to work around Clickjacking security issue (see this great paper for even more details). The main article explaining how X-FRAME-OPTION works is this: http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx
Basically, here’s what behaviour you get with different X-FRAME-OPTIONS values:
||browser will not render the iframe contents in any case|
||browser will only render the iframe contents if host page origin is the same as the iframe page origin|
||browser will only render the iframe contents if the iframe host is http://host|
Please note that specifying the header in META tag won’t work.
Good news – all browsers vendors copied this from Microsoft and now we’ve got all modern browsers supporting this header (Firefox 3.6.9, IE8, Opera 10.50, Safari 4.0, Chrome 4.1).
Unfortunately, for some reason only Opera and IE show a meaningful message why the frame was blocked, all others just display the empty iframe (it’s especially weird for Firefox, which should show the warning as per their bugzilla):
In any case, study the security papers I linked to above to understand how the attack works and what it can do to your visitors or your business.
However, if you strongly believe no one should embed your page in an iframe – then your silver bullet is to add
X-FRAME-OPTIONS: DENY to all the pages you serve.
P.S. X-FRAME-OPTIONS is now proposed to IETF: http://tools.ietf.org/html/draft-gondrom-frame-options-01