This morning I had to solve a problem that involved an application inside an IFrame not keeping it’s session state. I’d solved this problem many times before, a long time ago, in a galaxy far far away, but still it stumped me again!
In this example we had two client websites we’ll call site-a.com and site-b.com. Site-a.com had a page that contained an IFrame which sourced it’s content from site-b.com. The page on site-b.com allowed the user to log in to the application that resides on the site-b.com domain and then click on various links that would take them to other areas in the site-b.com application.
This worked perfectly in Firefox and Safari, but in IE7 it failed and would not let the user log in. After setting up a test environment on my virtual machine and repeating the bug I went looking for a solution.
It turned out that what was required was a declaration by site-b.com that it was okay to do what I was trying to do. It seems that as long as site-b.com declares that it’s safe then the browser assumes this to be the case and it all starts to work.
The way this is done is through adding P3P info to the header of the response. Essentially what this does is say to the browser that your application is okay with taking information from other domains. Rather than relying on external security measures, you’ve taken the steps yourself to develop a secure application. This sort of setting can also be used for single sign on situations too where your cookies need to be accessible across domains and applications.
Typically it’s as simple as adding :
header('P3P: CP="CAO PSA OUR"');
to the page. You could also add it on the server level if required, but in this case it all takes place in an extranet module so it’s perfectly suitable to be applied only on one page. There are quite a few options that you can find on the P3P Specification.
So that’s how you get cross domain cookies to work with PHP. It’s much the same in other web frameworks, you just need to work out how to modify the headers in the one you’re using.
What about the security issues with it?
I’m not sure what you mean?
Essentially all this is saying is that you certify your website is built to handle any exploits that the browser is trying to protect it from. So it’s up to you to either rely on browser security (not a great idea really) or to work on securing the site and explicitly say that the browser is free to expose your site to things it wouldn’t normally allow.
Check out the P3P spec and I think you’ll see what I mean. In reality I think it only effects IE for the most part.