Thursday, November 08, 2007

Facebook, IE and IFrames

I test my webapps so rarely in IE that when they break, I assume it is IE's fault.  I'm usually right.  Tell me if this has happened to you:  You're developing in an iframe situation where the master page is at a different domain than the inner page.  This, by the way, is exactly the situation for iframed Facebook applications.  You click on a link in your iframe, and then your frame blows up.

This is because IE's default "medium" privacy setting has an issue with cookies in that situation.  So whatever session you setup for yourself on that first page doesn't exist when you try to click through to the next page of your application.

The solution, as several sites have pointed out, is to set up a "compact privacy policy", or P3P header.  Google for things like "p3p iframe internet explorer" and you'll get all the hits you need for how to do it.

In my Rails controller I added this line:

before_filter  :set_p3p

which is a shortcut for "Before you do anything else, run the set_p3p method".  And, the method:

def set_p3p

   response.headers["P3P"]='CP="CAO PSA OUR"'

end

Presto, it should work.  Right?  Well, no.  At least, not for me.  It stayed broken, and that's where I got stuck, because everything I googled said that should work.

Here's where it got interesting.  Pull up the privacy policy for the page you're on.  IE7, at least, has this over on the far right under the "Page" button, "Web Page Privacy Policy."  This will bring up a dialog box that shows all the URLs that your current page has tried to access, and whether or not cookies are blocked for each.  And it's there that I found something very interesting.  One line - a reference to a Javascript file, of all things - was showing "blocked."  Odd, that, because all my other resources from my own domain were Accepted.

Know what it was?  The Javascript file in question actually didn't exist.  This was a bug that the designer had put in, an old reference to a file no longer used.  So something in IE was saying "You've asked me to include this file, I presumably got back a 404 on it, so I'm going to put it in the blocked category."

Since that file had nothing to do with my ability to login to my application I'm not really sure how it caused the crash it did, but when I took out the include, magically everything began working.  So perhaps IE has a policy that says "If any resources from this domain are blocked, then all are blocked."

Just googling for posterity's sake.  I didn't find anybody mentioning a ghostly blocking of cookies from non-existent javascript files.

 

3 comments:

Anonymous said...

A problem with iframes can also be caused by cookie settings and cross domain access.

IE at it's best!

Anonymous said...

The previous poster is correct, but I once experienced both problems at once - I was including a flash movie that did not exist AND i was experiencing problems with cookie settings and cross domain access. I managed to solve the problems with both, but the symptoms look similar - especially if the missing resource is not on the page the iframe initially loads.

Rylan B said...

https://gist.github.com/2765933

has my solution for Sinatra/Ruby in it. And a bit more description on the way to set this.