George V. Reilly

Third-Party Cookies

C is for Cookie

Over the last few weeks, I built a PHP ap­pli­ca­tion that overlays Approve 71 banners on profile pictures. The actual ap­pli­ca­tion is hosted in an iframe and lives on a server in a different domain, eq.dm, than the main server at ap­proveref­er­en­dum71.org.

This works fine in most browsers. Then we started getting reports that it wasn’t working in IE8 on Win7 RC1. The iframe content was blank.

Poking around, I found the problem with the Fiddler proxy. The landing page on eq.dm was supposed to stick some in­for­ma­tion into the PHP session, then redirect to a second page at the same site. The second page was in an endless loop, redi­rect­ing to itself. In Fiddler, I saw a different PHPSESSID cookie on each response, and no cookie in the requests.

After reading IE 8 only has access to session cookies, I told IE8 to Accept All Cookies and the iframe content appeared. That fixed it for me, but we could hardly ask people to lower their security sessions.

I created a P3P file for the second domain, using the IBM P3P Policy Editor. (KB 323752 has more background on P3P and third-party cookies.)

IE now worked at its default security level. Problem solved! Or so I thought.

A day later, we got reports of similar problems with Safari 4 on Mac OS X.

I sniffed the traffic with Wireshark. Same problem: the “third-party“ cookie wasn’t being accepted by Safari.

Un­for­tu­nate­ly, Setting cross-domain cookies in Safari indicated that there was no reasonable workaround.

We overcame the issue up playing some DNS games, which was only possible because we control both servers. The second server is now also acting as a subdomain of the first, at dev.ap­proveref­er­en­dum71.org. We used ini_set("session.cook­ie_­do­main",".ap­proveref­er­en­dum71.org") to scope the iframe cookies. I’ve tried it in a variety of Windows, Mac, and Linux browsers, and it works in all of them.

blog comments powered by Disqus
Review: March to the Stars » « Football and Brain Damage