关于cookie的"跨域"（一级域）

第三方cookie和第一方的cookie并不是技术上的区分，而是业务上的区别，我很赞同这句话，因为我觉得第三方和第一方都是一个相对的概念，其实我们操作的都是自己域下的cookie，只是在某种情景下的操作，我们称之为第三方域下cookie的操作

-------题记

注：此处讲的是跨一级域操作cookie，如果只是跨二级域的话，很简单，只需要设置cookie的domian为一级域名，并辅以path属性的设置即可；

关于跨域，首先我们要明确一个概念，根据安全策略，我们永远不可能操作第三域的cookie，比如在A域的页面试图去读取一个domian为B域的cookie；或者在域A的页面试图通过域A页面的JS或者来自域A的http请求返回让浏览器去写入一个domain为B域的cookie；

到底能不能跨域，跨的是什么域，我觉得这个是我们需要最开始弄清楚的地方，是后面操作一起的基础。因为有些事我们可以努力，有些事我们努力了也不会有结果。

记得曾经看到过一篇文章讲到，第三方cookie和第一方的cookie并不是技术上的区分，而是业务上的区别，我很赞同这句话。因为我觉得第三方和第一方都是一个相对的概念，其实我们操作的都是自己域下的cookie，只是在某种情景下的操作，我们称之为第三方域下cookie的操作。当然在这儿，我们假设我们已经对第一方和第三方cookie的定义有了完整准确的理解。

cookie的读写场景一般有两种，一般分为前台的JS的操作，和通过http请求传递到后台的读，及http响应的写操作。

前台的JS的读写是受同源策略限制的，我们永远只能将要写的cookie设置和当前载入js的文档为同一个域，就算是通过iframe引入的页面中的JS视图去读写的cookie也是只能和iframe的src是同一个域。

第二种一般发生在页面中包含了另外一个域的请求，比如iframe，img，script都可以。http请求一般都是携带cookie的，这个毋庸置疑，而且只能携带和请求同一个域下的cookie，但是当这个请求发生在另外一个域的页面中的时候，就会产生问题，这个时候对于主页面来说，你在我的页面请求读取不是我域下的cookie，也就是说你想跨域，这个时候他就不会让你这么轻易的得逞，关于这种情况的分析，下面会讲到。如果一个跨域的请求返回了一个写cookie的指令，前提是你写的是和自己请求的域是同一个域的cookie，如果是其他域的，就算和主域是同一个域，想都别想。这个时候你也不是这么容易办到的，因为对于主域来说，你又在想跨我的域来操作，肯定也不是那么容易让你得逞的。

现在我们先来假设这样一个场景，我们访问一个域A的页面（我们成为A_1页面），A_1页面的底部通过iframe引入一个域B的页面（我们称为B_1页面）;

此时我们关心的是这个发向域B的请求会不会携带域B的cookie和来自域B的响应能不能在导航栏为域A的页面的情况下写入cookie；

因为对于A页面来说，此时在来自它的window中有一个关于域B的cookie操作请求，此时就发生了我们常说的跨域操作cookie的情况。

我们首先先拿出结果，在一般情况下，也就是没有服务端p3p的干预的情况下，B_1的请求中是不会携带域B的cookie的，域A的就更别想了。而且B_1的响应中携带的cookie是能够返回的。但是不能写到内存或者硬盘中的。

但是在火狐中就完全不存在这个问题了，完全可以正常操作。

对于火狐中不存在这个问题就没有什么好讲的了，IE中不支持的话我们就得分析问题去解决了。

在这里有一个概念就不得不提了，因为没有这个概念，我们上面谈的问题都不是问题，那就是p3p，关于这个概念，或者称之为协议，我们可以上网了解。它大概可以分为两部分，一部分是浏览器端用户设置的隐私偏好（有这个部分的前提是浏览器支持p3p），和服务端的隐私申明。比如用户可以在IE浏览器中设置隐私级别，默认级别一般都是中。一部分是服务端在头信息关于当前网页隐私安全性的声明；浏览器在最后执行的时候会将隐私安全性的生命和用户设置的做对比，如果不匹配的话，会告知用户，由用户选择安全性的执行方案。


既然用户已经选择了不去允许域B的cookie写入，IE认为是不安全的，那么我们能做的修改就是修改服务端的隐私安全性声明了，具体怎么去加这个p3p的声明，网上有很多方法，百度一下就行，比如在response的header中添加一个头信息：P3P: CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"。

如果你看到这篇文章，发现有什么谬误之处，还请留言斧正，将万分感谢！