How does Iframe access Cookie and Session across domains

Recently do login system integration, including one of the key problems for in 1 series 1 background need barrier-free access to the other one in the system background, this system is provided by the third party a a cipher system, automatic login interface background is the analysis of their own, not alone, when the background from the series 1 by automatic login login interface, system jump straight to the back page, login backstage after a successful jump by URL couldn't specify here, can't control the jump of the page, if in the series 1 background need to link to the system background of a page, in addition to the default home page rather than the background, That is to put the menu function in the background of the third party system into our system 1 background.

For such a requirement, there will be a problem here. In order to access the background columns of the third party system normally, it is necessary to ensure that the system has been logged in, otherwise the user will be prompted to log in. Therefore, when clicking these menu links, the system must have been logged in.

In order to solve this problem, at the head page added a invisible iframe, pointing to the automatic login interface, this interface if normal access via a browser address bar, when a user name and password authentication and correct, will jump to the background system home page, because at that moment, on the one invisible IFRAME, so jump to the current background page does not have any effect. According to my design method, the system should be able to work normally.

But, since said but, that must have encountered a problem, otherwise here would not come such a big 1 turning point.

However, since all the systems here belong to different systems and the domain name is not the same, there is a situation that Iframe in IE cannot normally generate the third party system Cookie, but it can be generated in Firefox and other browsers. Therefore, when you visit IE, you always jump to the login page.

Here need to explain 1, here the third party system on our own server, just all the source code added!

Finally, after referring to the relevant information, it is found that in IE, COOKIE of the third party domain is prevented from being generated through IFRAME for security reasons. To solve this problem, MS provides that the third party COOKIE can be generated through IFRAME by setting P3P in HEADER header of HTTP.

In PHP, P3P HEADER header is set as follows:

header(' P3P: CP= 'CURa ADMa DEVa PSDo PSDo OUR BUS INT PRE COM COM NOI DSP COR');

Note: the P3P here takes effect only if it is added to the third domain to generate the Cookie file, otherwise it will not work.

Here is another problem. The third party system generates COOKIE in a page called admin.php in the background, and this page is overpacked. How can we do this? Depend, this method is too wonderful, why I did not think of, the colleague is really too talented, really admire of 5 body throw ground, of course, I admire him so 1, according to he said he also admired himself that night 1 night.

So the final solution is to name the original admin.php file admin_2.php, then create a new admin.php, and finally, in this file, add the P3P HEADER header above, and again include the admin_2.php file, the final code is as follows:

header(' P3P: CP= 'CURa ADMa PSDo OUR PUR INT DEM COM NAV OTC NOI DSP DSP DSP COR');
include "admin_2. php";

Finally, the problem is solved once and for all!

The title here is COOKIE and SESSION problem, in essence, it is basically 1 thing, SEESION finally saved through SESSION_ID to COOKIE source sky, and then through this SID to the server to find the corresponding SEESION data, as long as COOKIE SEESION_ID COOKIE to delete SESSION will be invalid.