Cannot set cookies in IFRAME in IE, even with P3P header
Asked Answered
U

2

6

I've seen many posts here on how to get cookies to work inside an iframe in IE, and I've tried several of the solutions, but so far have had no luck. Here's what I'm dealing with:

  • I have an iframe that is created through Javascript on a customer's site (a widget.) I have no control of the customer's site. I need to set cookies to keep the user logged in within the iframe, and it works in Chrome and Firefox, but not in IE 7/8. I haven't tested IE 6, but I assume it has the same problem.

  • I created a P3P policy using IBM's policy editor, and the editor said that the compact policy was acceptable under IE's security, whether it's set to Low, Medium, or High. The CP I'm using is:

P3P: policyref="/w3c/p3p.xml" CP="CAO DSP COR CURa ADMa DEVa PSAa PSDa CONi TELi OUR IND PHY ONL UNI COM NAV INT DEM CNT PRE" (I have tried several other CPs that people say work, but have seen no difference in the result.)

  • The webserver (NGINX) is serving this P3P header with every file. I am not serving it from code.

  • The p3p.xml file exists and matches the compact policy. The p3p.xml validates using the W3C P3P validator.

  • Even with the P3P header (no matter which one I tried), IE gives me the "evil eye" in the status bar at the bottom and will not let me set cookies. They show as Blocked in the privacy report.

  • I read Piskvor's post on SO about this topic: Cookie blocked/not saved in IFRAME in Internet Explorer but I have not been able to reproduce what he was able to do on his demo site: http://newmoon.wz.cz/test/page.php?send_p3p=1. I assume this is because I am getting the evil eye and he is not. I have done everything I've read about as a recommendation to get rid of th evil yet, yet it persists. Mocking me.

  • My test page is here if you want to try it out: http://truelike.com/js/bobs/frametest.php The set/read pages work fine when viewed outside of the iframe, but don't work at all inside when using IE.

  • For reference, I'm using PHP on the backend.

Any help at all would be much appreciated - we're getting desperate here.

Thanks!

Uriah answered 19/5, 2011 at 21:54 Comment(0)
U
4

So, I resolved this myself. It looks like the problem was with NGINX's HTTPUserIDModule (http://wiki.nginx.org/HttpUserIdModule). I had been using that to send the P3P header, but nginx wasn't sending the header consistently, perhaps due to this line in their documentation:

Directive assigns value for the header P3P, which will sent together with cookie.

I was seeing the headers come through when checking with curl or lynx, but not when I checked with Firebug or Charles. Perhaps there is a config option to fix this, but I couldn't find it.

Anyway, if you pull the header directive OUT of the HTTPUserIdModule and just send the header manually in code, it works. It would probably work if you manually send the header using the HTTPHeadersModule http://wiki.nginx.org/HttpHeadersModule, but I haven't tested this yet.

Once it was working through code, I saw that I didn't need the header on all files - having it only on the files setting/getting cookies was enough, contrary to a lot of the advice I've seen.

Also, my CP was apparently too aggressive, despite IBM's policy editor saying it was okay. I used a more basic CP, and that worked.

Uriah answered 20/5, 2011 at 15:16 Comment(4)
Did you use only a compact policy or also the p3p.xml file? Could you say which site did you use this policy on? I've been crashing my head against a wall for some time regarding IE8 with medium security and p3p policies.Morehouse
I used only the compact policy, specifically: header('P3P: CP="CAO PSA OUR"');Uriah
I'll try that. Do you need to use cookies to log in users?Morehouse
Yes, I do, among other things.Uriah
D
0

Changes with nginx 0.8.20
Bugfix: the "Set-Cookie" and "P3P" FastCGI response header lines were not hidden while caching if no "fastcgi_hide_header" directives were used with any parameters.

Nginx Changes log

Differentiation answered 29/7, 2013 at 9:26 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.