The Challenge:
IE blocks cookies from pages that are called in an iFrame. In my case this involved an ASP.NET application called from a Drupal CMS via a jQuery-based FancyBox.
Details:
Today I ran into an interesting IE problem that was tricky to track down.
A few years ago I inherited a simple but useful ASP.NET application that tracks the Latitude, Longitude, and Elevation of satellites for a geographic location.
This application works well for IE, Firefox, and Chrome when one browses to it directly. However, recently the third party company that maintains our corporate Web site was told to link to the application and all of a sudden I started hearing complaints about how it is unstable and is not working.
When I started looking into things it certainly seemed to be an IE issue… Chrome and Firefox would run the application without any problems. I tested several versions of IE with the same result: IE 6, 7, 8 & 9 all behaved the same way except for one user who has IE 7 for whom the application mysteriously worked.
The Solution:
Once I started stepping through the code it became clear that somehow the data being stored in the session was not being kept. Looking into the web.config file told the whole story: the session had been set to inproc and the cookieless option to false. So the application was storing session data in cookies on the client browser, which IE was rejecting when the application was called from inside an iFrame.
As soon as I switched the session attribute cookieless=true everything worked again like a charm in all browsers.
This is certainly an interesting quirk of IE that I was not aware of, but that appears to be enforced on purpose based on the W3C Platform for Privacy Preferences (P3P) Project (another good description can be found on Wikipedia). IE in all of its incarnations apparently considers a page within an iFrame 3rd party content and assigns it a very low level of trust, so any cookies will be blocked by IE if the page within the iFrame does not have a proper privacy policy.
Although there are a number of workarounds I believe that setting the session state to be handled by the server rather than client cookies is the best and does not violate the purpose of the W3C P3P . A second option however would be to add a P3P Policy Header to the Page header which would encourage IE to allow cookies to be set. I have not tested this, but the command would be:
HttpContext.Current.Response.AddHeader("p3p","CP=\"IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\"");
I hope this article has been helpful. I found this IE quirk/feature to be quite interesting.
References:
Justin Cooney 
1 thought on “IE Blocks Cookies in an iFrame: IE & P3P”