Third-party cookies and first-party cookies are not a technical distinction, but business differences. I agree with this statement, because I think third-party and first-party cookies are relative concepts. In fact, we operate They are all cookies under their own domain, but they are only operated in a certain situation. We call it the operation of cookies under a third-party domain ------- inscription
Note: This is about operating cookies across first-level domains. If it is only across second-level domains, it is very simple. You only need to set the domian of the cookie as the first-level domain name, supplemented by the setting of the path attribute;
Regarding cross-domain, first of all, we need to clarify a concept. According to the security policy, we can never operate the cookie of the third domain. For example, a page in domain A tries to read a cookie whose domian is domain B; or a page in domain A Attempt to return the browser to write a cookie whose domain is domain B through the JS of domain A page or the http request from domain A;
Whether it can be cross-domain and what domain is it crossed, I think this is the place we need to figure out at the beginning, and it is the basis for the subsequent operations. Because there are some things we can work hard for, and there are some things we work hard for, but there is no result.
There are generally two types of cookie reading and writing scenarios, which are generally divided into JS operations in the foreground, read operations passed to the background through http requests, and write operations of http responses.
The reading and writing of JS in the foreground is restricted by the same-origin policy. We can always only set the cookie to be written and the document currently loaded in js into the same domain, even if it is read and written through the JS view in the page introduced by the iframe. The cookie can only be of the same domain as the iframe's src.
The second type generally occurs when the page contains a request from another domain, such as iframe, img, and script. HTTP requests generally carry cookies. There is no doubt about this, and they can only carry cookies in the same domain as the request. However, when this request occurs in a page of another domain, problems will arise. At this time, for the home page On the face of it, you are requesting to read a cookie that is not under my domain on my page, that is to say, if you want to cross-domain, he will not let you succeed so easily at this time. The analysis of this situation will be discussed below. arrive. If a cross-domain request returns an instruction to write a cookie, the premise is that you write a cookie of the same domain as the domain you are requesting. If it is from another domain, even if it is the same domain as the main domain, don’t think about miss. At this time, it is not so easy for you to do it, because for the main domain, you are trying to operate across my domain, and it is definitely not so easy for you to succeed.
Now let's assume such a scenario, we visit a page of domain A (we become the A_1 page), and the bottom of the A_1 page introduces a page of domain B through an iframe (we call it the B_1 page);
At this point, what we care about is whether the request to domain B will carry the cookie of domain B and whether the response from domain B can write the cookie when the navigation bar is the page of domain A;
Because for page A, there is a cookie operation request about domain B in its window at this time, and the situation of cross-domain cookie operation that we often say occurs at this time.
We first come up with the result. Under normal circumstances, that is, without the intervention of the server p3p, the request of B_1 will not carry the cookie of the domain B, let alone the domain A. And the cookie carried in the response of B_1 can be returned. But it cannot be written to memory or hard disk.
But in Firefox, this problem does not exist at all, and it can operate normally.
There is nothing to talk about if this problem does not exist in Firefox. If it is not supported in IE, we have to analyze the problem to solve it.
There is a concept here that has to be mentioned, because without this concept, the problems we talked about above are not problems, that is p3p, about this concept, or protocol, we can learn about it online. It can be roughly divided into two parts, one is the privacy preferences set by the user on the browser side (the premise of this part is that the browser supports p3p), and the privacy statement on the server side. For example, users can set the privacy level in the IE browser, and the default level is generally medium. Part of it is the server's statement about the privacy and security of the current web page in the header information; the browser will compare the privacy and security life with the user's settings when it is finally executed. If it does not match, it will inform the user and let the user choose the security. Sexual implementation plan.
Since the user has chosen not to allow domain B's cookie to be written, IE considers it to be unsafe, so the only modification we can make is to modify the privacy and security statement of the server. Specifically, how to add this p3p statement, there are many online The method, Baidu is enough, for example, add a header information in the header of the response: P3P: CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR" .
Transfer: http://blog.csdn.net/fish_no7/article/details/11266401