Lessons learned from dealing with iframes
Iframes are a pretty cool bit of html. Basically, what they let you do is seamlessly include another webpage in your existing page. Couple that with a reference to a CSS that a partner provides and you have a recipe for easy integration into a partner site with limited requirement for maintenance.
Unfortunately, nothing is ever as easy in practice as it is in theory.
We just rolled out our first iframe implementation in one of our application stacks. This is what we have learned — so far.
- Test in an iframe – This one is the most annoyingly obvious. While in theory, loading the page that is being called by the iframe directly should be the same and loading it within the iframe, in practice, it is not. We do some trickiness around redirects and those worked fine outside of an iframe, but do not within one. Google has lots of hits for redirects and iframes so we appear to have lots of company in this problem. The solution ended up being surprisingly simple — stop being tricky.
- Use a separate test domain – This one, which obvious also, is less annoyingly so. When an external entity is going to reference your page, pretend to be an external entity. For our testing, both the referencing page and iframe page are in the same domain, so the notion of a 3rd party is not in the mix like it would be once deployed to production. Most companies has more than one domain registered, so you should with a little prodding be able to fake a page being on a different domain creating an artificial 3rd party.
- P3P – The issue of a 3rd party mentioned about is especially important when it comes to cookies. IE7 by default blocks cookies by 3rd parties unless there is a Personal Privacy Policy (P3P) which clearly states what the information collected and stored is and what it will be used for. Learn more able P3p here, here and here