IE, P3P, IFrame and blocked cookies (works until page host page has personal information requested)

Question

My company has a little widget that plugs into shopping carts. We are running into a problem where setting cookies in IE7 is not working. This is happening because we are a 3rd party because we are embedded into the site via an iframe.

I have seen several post that say the way to solve this problem is by putting a P3P compact policy in the header. As mentioned:

Cookie blocked/not saved in IFRAME in Internet Explorer

I have verified that my P3P policy is in my HTTP header. And it actually works for the first page/step of the shopping cart site, but as soon as there is personal information on the page (like name, address, phone, etc), IE blocks my site and my cookie.

I have tried several different P3P policies and they all don't work at the same place. I have also used the IBM P3P tool to generate my own special P3P policy, but it still doesn't work.

I am at a complete loss.

Answer 1

This probably won't help anyone else, but I was banging my head against the wall for weeks over this one. It turns out that IE 7 won't allow 3rd-party cookies to be set, even with a valid P3P compact policy if the HTML meta tag for Content-Type has a different character set declaration on the page with the iframe from the page within the iframe.

Answer 2

I had a similar issue sometime ago myself. Make sure you add the p3p header to all the pages inside the iframe.

Answer 3

There is a very insidious Internet Explorer 7 bug to be aware of: on a 304 ("Not Modified") request inside an iframe the P3P header will not be sent by the web server as per the RFC (unless you are using IIS, which doesn't care about such things). IE7 will actually delete any cookie set during that specific request.

This will have the effect you describe above so perhaps that's what's going on. IE6 & IE8 (and every other browser) work as expected.

Answer 4

The Fiddler web debugger (www.fiddler2.com) has a "Privacy" inspector tab on the response which decodes the P3P tokens into their meanings. There's a link at the bottom of the inspector which points to the MSDN article that shows which policies are considered "acceptable" by default.

Note, of course, that P3P policies are a Legal declaration, so you must be sure that your use of cookies matches what you claim in P3P.

Answer 5

We ran into the problem described above, with the 304 requests (cached content). Our load balancer was setting a session cookie, but the Apache web server would not include the P3P header for requests that resulted in the 304 result code. So then the session info would get messed up.

So this is something to be aware of with Load Balancers. When they set a cookie for persistence tracking, make sure it also generates the P3P header, to make sure they are always sent in tandem.

Answer 6

I had the same issue and decided to take the Google/Facebook approach and fake out the P3P header. I did end up having some problems though.

1. First you must make sure that you pass that header with ALL.
2. If you are using the Visual Studio Development Webserver the P3P header will be ignored for some reason. So host your app in IIS.

Problem 1:

To return that header with all of your requested actions add this to your Global.asax, customizing it for your needs of course:

 protected void Application_BeginRequest(Object sender, EventArgs e) {
            //
            HttpContext.Current.Response.AddHeader("P3P", "CP=\"This is not a P3P policy! See http://mydomain.com/privacy-policy for more info.\"");
        }

Problem 2:

Pretty self explanatory. Host your project in IIS.

I made the decision to bypass the P3P when I read that W3C had not worked on or updated the standard since 2006. That to me, means it is dead and we just have a major browser enforcing a dead standard. The project was mine, I was/am the client. So if you plan on taking the same actions and you're not writing something for yourself, check with the powers that be.

Cheers!

Answer 7

The cookie should have expires=Fri, 19-Dec-14 18:00:40 GMT and not max-age.

This is controlled in Apache mod_usertrack by the config CookieStyle=Netscape