Sometimes, we take things for granted.

For example, when programming one of our large applications, we took for granted that users would accept our cookies. Why wouldn’t they? We just store a simple session id, we don’t do anything nefarious, and the only thing we even ask a user for is their zip code. So of course, we do what the smart developers do and build in sanity checks: if we don’t have a session cookie, something went wrong, so bail out.

Unfortunately, when I wasn’t paying attention, we sold the client on the idea that they could embed our application in whatever website they wanted through the magical use of iframes.

If you’ve guessed our problem, pat yourself on the back, and feel free to skip to the bottom for how we solved it.

The problem is, of course, that user’s don’t like these so-called “third-party cookies.” Unscrupulous ad banner companies will use iframes to show their advertisements on target websites, and when they load their banner they also plant a cookie in your computer so they can track where you’ve been. Turns out that people don’t like invasions of their privacy so you can sell them crap, so the Internet Explorer family of browsers (specifically IE6 and IE7) will block cookies from being set if the URL for the cookie doesn’t fit with the one you typed into your browser.

Which meant our application crashed and burned. If we’d been smart we’d have seen this in testing, but all the people who had been testing this had also tested the application outside of the iframe (and indeed, it can be used both ways), so they already had a valid cookie on their machine that the application could use.

So, we did a lot of reading about P3P, which is a way of telling the browser that we don’t plan on using any identifying information. Specifically we used IBM’s P3P Policy Creator and this excellent reference to help us create our P3P policy, XML, and compact HTTP header solution.

And a few hours and many cans of Mountain Dew later, we had a solution! It worked! Half the time.

Some machines would accept the cookies, no problem. Other machines with seemingly identical IE settings would not. It seems that I’m doing all the right things in my P3P to indicate that we’re not collecting any personally identifiable information on the user and that we’re not retaining it or examining it except for the purpose of statistics, but still IE occasionally blocks it. It would be great if IE would tell us what values in our P3P indicate that it doesn’t like us, but no such luck.

I could spend another few hours screwing with the privacy policy, and that might get us somewhere, but I’ve failed to take into account two edge cases:

• Users that have their cookie settings set to auto-block all third party cookies
• Users that have utilities that auto-scrub third party cookies.

So we might as well just bite the bullet and propagate the session id in the URL and generate it as a constant in our javascript to support our AJAX calls. Is it the cleanest way of doing it? No. A lot of people would say that trying to store state over a stateless protocol is a pointless task anyway, but they’re curmudgeons and I’m already off their lawn.

We have learned a valuable lesson today: iframes are made of weakness. From now on, every time a coworker says “no, we can just put it in an iframe” I’m going to cut his access to our SVN repositories until he apologizes.