关于P3P协议与跨域

关于p3p 简洁策略,以及浏览器的支持情况.

简述部分摘自某本关于P3P隐私策略的书籍.

而部分详细的表格来自w3.org.

而相关测试数据出自本人测试.如有遗漏或错误,欢迎指正.

相关资源:

1. http://www.w3.org/P3P/

2. http://www.w3.org/TR/2002/REC-P3P-20020416/

简述:

从本质上来说，P3P 策略是由一系列多选项问题的答案组成的，因此，它并不总像一个人类可读的隐私策略那样包含许多信息细节（例如，用英语或者其他某种口语语言写成的策略是用来让人阅读的,而不是让计算机识别的）。P3P策略的标准格式使它便于自动处理。同 样 ，P3P规范也包含有用于请求和传输P3P策略的协议.P3P协议所基于的HTTP协议与 Web 浏览器用来与 Web服务器进行通信的 HTTP 协议相同。如图 1-1 所示，P3P 的用户代理使用标准的 HTTP 请求从 Web 站点上一个众所周知的地方获取 P3P 策略引用文件，并发送给发出请求的用户。这个策略引用文件指出了Web站点上各个部分所应用的P3P策略文件的位置。整个站点有可能只应用了一种策略，也可能是网站的不同部分分别应用了几种策略。这样用户代理就可以根据用户的选择来获取合适的策略，将其解析出来并采取相应的动作

P3P 也允许站点在其他位置放置策略引用文件。在这些情况下，站点在声明策略引用文件的位置时，必须使用一个特定的 HTTP 报头，或者在应用了 P3P 策略的H T M L 文 件 内 嵌 入 一 个 L I N K 标 记 .

不论在何时设置cookie都可以用特定的HTTP报头来传送一个可选的 P3P 简洁策略.简洁策略是完整 P3P 策略的一个短小摘要，仅描述了与cooki e 相关的数据处理方式，并且不需要P3P 策略的完整的表达性能.

如何使Web站点支持P3P:
从技术角度看，使 Web站点支持 P3P 是一个很容易的过程。但是，它要求网络运营商在审视数据处理方式时比以前更加仔细，并要求他们协调域内各个主机上的策略和处理方式。以下是如何使站点支持P3P 技术的具体步骤。

1. 创建一个隐私策略。
2. 分析 cookie 的使用情况以及您的站点上的第三方内容。
3. 确定要对整个站点应用一个P3P策略还是对站点的不同部分应用不同的P3P 策略。
4. 为站点创建一个或几个 P3P 策略。
5. 为站点创建一个策略引用文件。
6. 为 P3P 配置服务器。
7. 测试站点，以确定它确实支持 P3P。

大多数支持P3P 的Web站点会在每台服务器上放置一个P3P策略引用文件，同时它还会在中央服务器上放置一个或多个P3P策略。这些站点也会将自己的服务器配置为用户在设置 cooki e 时发送 P3P 的简洁策略。P3P 策略包括以下信息：

● 如何与拥有该站点的公司、组织或个人进行联系的信息。
● 用户是否可以查找该站点的数据库中保存了自己的哪些个人信息。
● 如何解决与站点之间有关隐私的纠纷（如客户服务台、隐私封印以及与隐私相关的法律等）。
● 所收集数据的种类。
● 所收集数据的使用方式，以及用户是否能选择接受或拒绝这些用途。
● 信息是否会被共享以及何时被共享，用户是否有选择的权力。
● 对所收集的用户信息进行定期清除的策略。

有很多软件工具可以帮助Web站点开发人员开发支持P3P的站点。

要想了解最新的P3P 工具列表，请访问http://p3ptoolbox.org/tools/     和     http://www.w3.org/P3P/implementations/

---

简洁策略对应的 HTTP Response Header :

相关资源: http://www.w3.org/2002/04/P3Pv1-header.html 

Compact Policies (简洁策略)

简洁策略,本质上就是P3P策略的一个摘要. 他们的作用是,使用户代理,可以快速敏捷的获取到站点的P3P策略信息,所以是对性能有益的.

为了深入的解释简洁策略,按照 P3P1.0[4]规范,我们列出下面这些限制性的语法：

compact-policy-field         =   `CP="` compact-policy `"`

compact-policy                = compact-token *(" " compact-token)

compact-token                = compact-access           |

                                        compact-disputes         |

                                        compact-remedies         |

                                        compact-non-identifiable |

                                        compact-purpose          |

                                        compact-recipient        |

                                        compact-retention        |

                                        compact-categories       |

                                        compact-test 

compact-access           = "NOI" | "ALL" | " CAO" | "IDC" | "OTI" | "NON"

compact-disputes            = "DSP"

compact-remedies          = "COR" | "MON" | "LAW"

compact-non-identifiable = "NID"

compact-purpose            = "CUR"        | "ADM" [creq] | "DEV" [creq] | "TAI" [creq] |
                                       " PSA" [creq]  | "PSD" [creq] | "IVA" [creq] | "IVD" [creq] | 

                                       "CON" [creq] | "HIS" [creq] | "TEL" [creq] | "OTP" [creq]

creq                              = "a" | "i" | "o"

compact-recipient       = " OUR" | "DEL" [creq] | "SAM" [creq] | "UNR" [creq] |
                                        "PUB" [creq] | "OTR" [creq]

compact-retention          = "NOR" | "STP" | "LEG" | "BUS" | "IND"

compact-category           = "PHY" | "ONL" | "UNI" | "PUR" | "FIN" | "COM" |

                              "NAV" | "INT" | "DEM" | "CNT" | "STA" | "POL" | 

                                        "HEA" | "PRE" | "LOC" | "GOV" | "OTC"

compact-test                  = "TST"

我们常用的简洁策略的 P3P头为 -   P3P : CP=CAO PSA OUR （其实, CP=. 就可以了.或者其他任何值都是可以的）分别对应了 :

　　compact-access(访问)    :  CAO -  contact-and-other 

Identified Contact Information and Other Identified Data: access is given to identified online and physical contact information as well as to certain other identified data.

直译 : 被识别的联系信息,和其他被识别的数据: 网上,或现实中的联系信息,和某些被识别的数据,允许被访问. 

我的理解: 应该是, 允许被确认的信息和数据的访问. (允许第三方cookie的读写)

　　compact-purpose(目的)  :  PSA -  pseudo-analysis .这个就不放解释了,字面意思很明显, 目的就是做身份验证、分析

　　compact-recipient(受体) :  OUR - ours

Ourselves and/or entities acting as our agents or entities for whom we are acting as an agent: An agent in this instance is defined as a third party that processes data only on behalf of the service provider for the completion of the stated purposes. (e.g., the service provider and its printing bureau which prints address labels and does nothing further with the information

直译 :  我们自己,以及（或）实体作为我们自己的代理,或被我们所代理方的实体:这种情况下的代理,被定义为,相关进程数据,代表服务提供者,用来完成其所设定服务的,第三方.(就好像,一个印刷局作为提供打印服务的,服务提供者,其只负责打印标签神马的,但是却不会进一步,对相关的信息,做任何事情 )

我的理解:声明使用相关信息的人是谁.这里声明是第三方自己, 或作为代理.需要操作第三方Cookie. 大概就是这个意思.

　　ps : 其他项就不列举,基于浏览器中只有IE支持.(chrome 部分支持).这一事实.深入研究没有必要. 如果你有兴趣,可以去相关链接查看文档.

---

用户代理对简洁策略支持的状况 和实现, 拿IE6来说:

IE6 ，可以自动核对设置了 cooki e的站点的 P3P 简洁策略。用户也可以配置 IE6 来过滤那些没有简洁策略的cookie，或那些具有与他们的偏好不相匹配的简洁策略。当 cookie 被阻止时，IE6还会在浏览器的右下角显示一个“眼睛”符号。用户也可以从Vi ew（查看）菜单中选择Privacy Report（隐私报告）命令来让 IE6 获取站点的 P3P 策略，并生成及显示一个人们可读取的版本

对于众多提示性的反馈,是十分符合 P3P隐私策略的.即用户代理应该在恰当的时候,提醒用户.

---

已测知的问题:

IE6 第三方cookie 在有p3p头(使用p3p简介策略时) ,JS虽然有读写权限,但是在写的时候有个bug. 即,对于某第三方页面,如果是首次读到.其P3P头的话,则 js的写权限是没有的.必须要第二次访问到这个页面,且这个页面存在第三方cookie操作时,才允许JS写入Cookie.当然,读是一直没问题的.

Safair3,则顽固到连Post方式都无法写入第三方Cookie.

Safari4+ 系列则有自己一套隐私策略,而完全无视P3P的存在:

在其不支持P3P的情况下,其策略为. 默认设置浏览器禁止第三方Cookie操作.那么此时,无论JS 还是 HTTP ，都无写入Cookie的权限,而仅具备读的权限. 

除非, 进行表单Post时,才允许第三方Cookie的写入.参考下面的代码: (在//www.a.com/test.htm 中的代码)

if(Safari4或Safari5){

    var ifm = document.createElement('iframe');

    ifm.name ="postforcookie";

    ifm.src="about:blank";

    document.body.appendChild(ifm);

   

    var form = document.createElement('form');

    form.target = 'postforcookie';

    form.action = '//www.php.com/test.php';

    document.body.appendChild(form);

   

    Cookie.setCookie = function () {

        form.submit();

    }

}  

假设,setCookie是一个写入第三方Cookie的函数,则在Sacari4,Sacari5下劫持他们,触发代码中 form的submit即可.

此时,如果//www.php.com/test.php，有写入Cookie的操作.则可以保证第三方Cookie被写入.

---

默认不禁止第三方cookie的浏览器测试:

测试为在下列浏览器中,禁止第三方Cookie,并配置简洁P3P策略.

Firefox下  :

Firefox下禁止第三方Cookie后，很直接, 无论HTTP 还是 JS都无法读写Cookie.

Chrome:

Chrome10 开始 支持用户自定义是否允许在 地址栏: about:flags 中配置 是否允许第三方cookie.

而之前的版本需要通过, 选项-高级选项-隐私权-内容设置-拦截第三方cookie 来配置.

对于chrome9 和之前的Dev版本来说,通过选项配置禁止第三方cookie后, 在配置P3P简洁策略后, JS 可读cookie,但不能写,而 HTTP方式,则都可以.

而chrome10+ 无论选择什么方式设置, 只允许HTTP、JS读,但是不允许写.

而Chrome的非Dev版, 甚至没有提供第三方Cookie的隐私策略选项. 有的仅仅是,关于Cookie的站点允许列表,或者主动访问过的站点的Cookie.

Opera:

通过 工具-首选项-高级-Cookie-仅接受来自我访问站点的Cookie 来设置禁止第三方Cookie.

Opera的有趣之处在于,一但禁止第三方Cookie,则 P3P头毫无意义,而Opera自身的隐私策略则非常有趣,

允许JS 的读写,以及HTTP的读, 但是禁止HTTP 对Cookie的写入.

---

总结:

浏览器	默认允许第三方Cookie	是否支持P3P	禁止第三方Cookie后,配置P3P简明策略头的效果	补充
IE6	否	是	HTTP可读写Cookie JS可读Cookie 首次读到P3P头,JS无写Cookie权限.第二次才OK (第二次.直接Cache.也不行.除非第一次非Cache并读到p3p头.后面我会提到解决方案.)	避免JS的写操作
IE7-IE9	否	是	HTTP、JS,可随意读写.	-
FireFox	是	否	HTTP、JS都不可读写	-
Chrome	是	部分支持,趋势-否	趋势为HTTP、JS可读不可写.	-
Safari	否	否	HTTP、JS可读不可写	借助Post提交表单,实现写操作.
Opera	是	否	JS可读写 HTTP可读不可写.	-

建议:

1. 其实P3P简洁策略,可以最简写成: P3P:CP=. 就OK啦,也就是说IE对P3P简介策略的支持，属于搞笑级别的.根本不看内容,至少对于第三方操作cookie是如此的.

2. IE6的实现有bug.需要注意.首次访问第三方页面,JS无法写入第三方Cookie的bug.建议尽量避免JS对Cookie的写操作.

3. 要搞定Safari,需要借助后台至少配置一个APP,与前台配合.

4. 对于第三方来说,建议避免使用JS操作Cookie,最多用来读,而不是写. 除非是和登录验证有关,否则建议使用Storage代替Cookie的使用.

最后:

如果你非要用在ie6下，用js写cookie. 那么有一个很悲剧的做法.. 服务器端给资源配置可缓存.(包括反向代理和客户端.) 然后想办法在IE6的时候刷新一次页面.这样就ok了. 刷新时一定要用 location.reload(false)  即先忽略客户端缓存.尝试304服务器端校验客户端缓存可靠性..这样做的好处是.即保证了 cookie的写入性. 又保证,如果页面是静态资源.则反向代理的可用性.. 否则还是直接用动态资源,http方式去写好了.  需要注意的是.除了页面刷新.譬如其他方式加载页面资源.试图通过预读其p3p简介策略头.是无效的. 比如 用 script type="text/c" 方式去预读一次. 如果你有这个想法。还是早早放弃的好. 

 

============================================================================================

网上看了别人介绍的一片文章，说使用P3P可以完成跨域COOKIE操作，感觉很COOL，不过没有提供源代码，我胡乱写了一下，大家看看。

实际工作中，类似这样的要求很多，比如说，我们有两个域名，我们想实现在一个域名登录后，能自动完成另一个域名的登录，也就是PASSPORT的功能。

我只写一个大概，为了测试的方便，先编辑hosts文件，加入测试域名（C:\WINDOWS\system32\drivers\etc\hosts）

127.0.0.1        www.a.com
127.0.0.1        www.b.com

首先：创建 a_setcookie.php 文件，内容如下：

<?php
//header('P3P: CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"');

setcookie("test",$_GET['id'],time()+3600,"/", ".a.com");
?>

然后：创建 a_getcookie.php 文件，内容如下：

<?php
var_dump($_COOKIE);
?>

最后：创建 b_setcookie.php 文件，内容如下：

<script src="http://www.a.com/a_setcookie.php?id=www.b.com"></script>

－－－－－－－－－－－－－－－－－－－－－－－－－－－－

三个文件创建完毕后，我们通过浏览器依次访问：

http://www.b.com/b_setcookie.php
http://www.a.com/a_getcookie.php

我们会发现，在访问b.com域的时候，我们并没有在a.com域设置上cookie值。

然后我们修改一下a_setcookie.php文件，去掉注释符号，a_setcookie.php即为：

<?php  
header('P3P: CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"');  

setcookie("test",$_GET['id'],time()+3600,"/", ".a.com");  
?>

再次通过浏览器依次访问：

http://www.b.com/b_setcookie.php
http://www.a.com/a_getcookie.php

这次，你会发现在访问b.com域的时候，我们设置了a.com域的cookie值。

末了补充一句，似乎只有IE对跨域访问COOKIE限制比较严格，上述代码在FIREFOX下测试，即使不发送P3P头信息，也能成功。

==========================================

通过Fiddler可以方便的知道上面P3P代码的含义

P3P Header is present:
CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"

Compact Policy token is present. A trailing 'o' means opt-out, a trailing 'i' means opt-in.

CURa
Information is used to complete the activity for which it was provided.

ADMa
Information may be used for the technical support of the Web site and its computer system.

DEVa
Information may be used to enhance, evaluate, or otherwise review the site, service, product, or market.

PSAo
Information may be used to create or build a record of a particular individual or computer that is tied to a pseudonymous identifier, without tying identified data (such as name, address, phone number, or email address) to the record. This profile will be used to determine the habits, interests, or other characteristics of individuals for purpose of research, analysis and reporting, but it will not be used to attempt to identify specific individuals.

PSDo
Information may be used to create or build a record of a particular individual or computer that is tied to a pseudonymous identifier, without tying identified data (such as name, address, phone number, or email address) to the record. This profile will be used to determine the habits, interests, or other characteristics of individuals to make a decision that directly affects that individual, but it will not be used to attempt to identify specific individuals.

OUR
We share information with ourselves and/or entities acting as our agents or entities for whom we are acting as an agent.

BUS
Info is retained under a service provider's stated business practices. Sites MUST have a retention policy that establishes a destruction time table. The retention policy MUST be included in or linked from the site's human-readable privacy policy.

UNI
Non-financial identifiers, excluding government-issued identifiers, issued for purposes of consistently identifying or recognizing the individual. These include identifiers issued by a Web site or service.

PUR
Information actively generated by the purchase of a product or service, including information about the method of payment.

INT
Data actively generated from or reflecting explicit interactions with a service provider through its site -- such as queries to a search engine, or logs of account activity.

DEM
Data about an individual's characteristics -- such as gender, age, and income.

STA
Mechanisms for maintaining a stateful session with a user or automatically recognizing users who have visited a particular site or accessed particular content previously -- such as HTTP cookies.

PRE
Data about an individual's likes and dislikes -- such as favorite color or musical tastes.

COM
Information about the computer system that the individual is using to access the network -- such as the IP number, domain name, browser type or operating system.

NAV
Data passively generated by browsing the Web site -- such as which pages are visited, and how long users stay on each page.

OTC
Other types of data not captured by the above definitions.

NOI
Web Site does not collected identified data.

DSP
The privacy policy contains DISPUTES elements.

COR
Errors or wrongful actions arising in connection with the privacy policy will be remedied by the service.

=========================================================================================================

网上现在有很多关于跨域设置cookie的文章，但大多数都是php的文章，网上仍然有很多关于jsp p3p的设置，但是必须要将浏览器的隐私设置成低才可以跨域设置cookie.查了n多文章发现他们都搞错了！(真郁闷死了，自己没有解决干什么要贴在自己的博客中？！害得我好惨！^@^)
下面是一个例子:
首先在hosts文件中设置（其中的192.168.73.1为您本机的ip,我写成127.0.0.1不行，可能是公司的域的设置问题）
192.168.73.1       www.a.com
192.168.73.1       www.b.com
[1]编写文件
b_setcookie.jsp

Java代码  

1. <%@ page contentType="text/html; charset=utf-8" %>   
2. <%    
3.    response.addHeader("Cache-Control", "no-cache");   
4.    response.addHeader("Expires", "Thu, 01 Jan 1970 00:00:01 GMT");    
5.    String ssocookie="www.sso12345678910.com";   
6.  %>   
7. <script src="http://www.a.com/mp/test/a_setcookie.jsp?id=<%=ssocookie%>">   
8. </script>  

<%@ page contentType="text/html; charset=utf-8" %>
<% 
   response.addHeader("Cache-Control", "no-cache");
   response.addHeader("Expires", "Thu, 01 Jan 1970 00:00:01 GMT"); 
   String ssocookie="www.sso12345678910.com";
 %>
<script src="http://www.a.com/mp/test/a_setcookie.jsp?id=<%=ssocookie%>">
</script>

a_setcookie.jsp

Java代码  

1. <%   
2. response.setHeader("P3P","CP=\"CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR\"");   
3. String domainId=request.getParameter("id");   
4. Cookie _cookie=new Cookie("test",domainId);   
5. _cookie.setMaxAge(30*60*100);    
6. _cookie.setPath("/");   
7. response.addCookie(_cookie);   
8. %>  

<%
response.setHeader("P3P","CP=\"CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR\"");
String domainId=request.getParameter("id");
Cookie _cookie=new Cookie("test",domainId);
_cookie.setMaxAge(30*60*100); 
_cookie.setPath("/");
response.addCookie(_cookie);
%>

a_getcookie.jsp

Java代码  

1. <%@ page contentType="text/html; charset=utf-8" %>   
2. <%   
3.    Cookie cookies[]=request.getCookies(); // 将适用目录下所有Cookie读入并存入cookies数组中  
4.     
5.    Cookie sCookie=null;    
6.    String sname=null;   
7.    String name=null;   
8.    if(cookies==null) // 如果没有任何cookie  
9.      out.print("none any cookie");   
10.    else  
11.    {   
12.      out.print(cookies.length + "<br>");   
13.      for(int i=0;i<cookies.length; i++) // 循环列出所有可用的Cookie  
14.      {   
15.        sCookie=cookies[i];   
16.        sname=sCookie.getName();   
17.        name = sCookie.getValue();   
18.        out.println("comment==>>>"+sCookie.getComment()+"\n");   
19.        out.println("getDomain==>>>"+sCookie.getDomain()+"\n");   
20.        out.println("getSecure==>>"+sCookie.getSecure()+"\n");   
21.        out.println("getVersion==>>"+sCookie.getVersion()+"\n");   
22.        out.println("cookiename==>>"+sname + "->" + "cookievalue==>>>"+name + "<br>");   
23.      }   
24.    }    
25. %>  

<%@ page contentType="text/html; charset=utf-8" %>
<%
   Cookie cookies[]=request.getCookies(); // 将适用目录下所有Cookie读入并存入cookies数组中
 
   Cookie sCookie=null; 
   String sname=null;
   String name=null;
   if(cookies==null) // 如果没有任何cookie
     out.print("none any cookie");
   else
   {
     out.print(cookies.length + "<br>");
     for(int i=0;i<cookies.length; i++) // 循环列出所有可用的Cookie
     {
       sCookie=cookies[i];
       sname=sCookie.getName();
       name = sCookie.getValue();
       out.println("comment==>>>"+sCookie.getComment()+"\n");
       out.println("getDomain==>>>"+sCookie.getDomain()+"\n");
       out.println("getSecure==>>"+sCookie.getSecure()+"\n");
       out.println("getVersion==>>"+sCookie.getVersion()+"\n");
       out.println("cookiename==>>"+sname + "->" + "cookievalue==>>>"+name + "<br>");
     }
   } 
%>

测试时依次请求
http://www.b.com/mp/test/b_setcookie.jsp
http://www.a.com/mp/test/a_getcookie.jsp
便可看到通过跨域设置的cookie的值！

===================================================================================================

一、

在IE中，页面通过FRAME，JS，IMG等引用其他域名页面的时候，P3P协议会阻止引用也的cookie。
举例说明：
在B.COM中，
    <iframe width=300 height=300 src="”http://www.a.com/test.php”" mce_src="”http://www.a.com/test.php”" > 
    <iframe width=300 height=300 src="”http://www.a.com/test.php”" mce_src="”http://www.a.com/test.php”" >
此时，test.php中产生的cookie将会被阻止，而不会记录下来
这种情况下，我们引入P3P header，情况就改变喽~

    P3P header允许跨域访问隐私数据，从而可以跨域set-cookie成功

在www.a.com/test.php中这样写：
    header(’P3P: CP=”CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR”‘); 
    header(’P3P: CP=”CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR”‘);
cookie就可以跨域了~
这种方法在单点登陆中被别广泛应用~

 

二、

 

目前在整合几个应用时，遇到了iframe无法获取cookie(session)的问题，经过google，终于把这个问题解决了，现在记录一下。
   我的需求是这样的。
   有一个应用是用.net开发的，主要是控制用户登录，用户访问权限的，部署在上海机房。现在就叫A应用吧
   还有一个应用是用java开发，主要是具体业务的操作。部署在北京机房，这里叫B应用吧
   由于已经有一个用户管理和权限的应用程序，所以java 开发的这个Ｂ应用就没有开发用户权限的功能，想直接使用.net的Ａ程序。

  用户访问的流程是这样的：
    1.用户先在A处登录，A设自己的cookie,在A的菜单里有去B应用的链接
    2.当用户点去Ｂ应用的链接时，Ａ在链接上自动加上这个用户的token,传给Ｂ系统
　   3.当B系统接收到请求后，把这个用户的token信息设成自己系统的cookie，（Ｂ系统里有表单post操作，如果不设 cookie,session，那么每个请求不管ＧＥＴ还是ＰＯＳＴ都要明确带着该用户的token信息，对于系统的改造量比较大，另外以后换权限验证方法改动也比较大。）
　　4.用户在Ｂ系统里的每次操作都没有明码带用户的token，所以每次都要去cookie得到token信息，然后发送一个http请求去Ａ，让Ａ系统验证这个用户是否有权限访问。
    5.如果Ａ系统的接口返回可以访问的状态报告，那么Ｂ继续执行；如果Ａ系统指示没有权限访问，那么Ｂ系统提示访问受控警告信息。

　　一切开发都完成，到整合上线时，发现这个流程走不通，百思不得其解，想了半天也不知道 怎么回事，google了半天，才发现原来是ie在捣鬼，IE不允许跨域访问cookie(好象firefox没问题，ie自6.0以后改用w3c组织的 P3P协议了)，再看看我的应用，在第二步设的cookie，在第三步以后所有Ｂ应用的访问请求，ie都把B应用的cookie blocked掉了（因为用户的访问是从A应用发起，从A应用访问B应用的东东，算跨域访问，IE认为有安全问题）。。。。（IE状态栏有一个红眼睛的 button,点开可以看到哪些cookie给blocked掉了）

     知道原因就好办了，再google知道可以用P3P header可以解决问题！
     下面是java的解决办法之一，也是我的解决办法，不过个方法不太好：
     直接往响应里加一个P3P的header
     response().addHeader("P3P", "CP=/"IDC DSP COR CURa ADMa OUR IND PHY ONL COM STA/"");

其中CP=“XXX XXXX”这些是有具体含义的：
     CP就是compact policies的意思，
    另外header的值也可以是policyref="http://myhost/P3P/PolicyReferences.xml",就是指定一个策略文件。

具体请看这里.


下面是摘抄的一段Compact Policies的具体取值范围和设值含义。

 Compact Policies

Compact policies are essentially summaries of P3P policies. They can be used by user agents to quickly get approximate information about P3P policies, therefore improving performance.

For an in-depth explanation of compact policies, we refer to theP3P1.0[4] specification. Here, we limit to stating the syntax:

compact-policy-field  = `CP="` compact-policy `"`

compact-policy        = compact-token *(" " compact-token) 

compact-token         = compact-access           |
                        compact-disputes         |
                        compact-remedies         |
                        compact-non-identifiable |
                        compact-purpose          |
                        compact-recipient        |
                        compact-retention        |
                        compact-categories       |
                        compact-test 

compact-access        = "NOI" | "ALL" | "CAO" | "IDC" | "OTI" | "NON"

compact-disputes      = "DSP" 

compact-remedies      = "COR" | "MON" | "LAW"

compact-non-identifiable = "NID" 

compact-purpose       = "CUR"        | "ADM" [creq] | "DEV" [creq] | "TAI" [creq] | 
                        "PSA" [creq] | "PSD" [creq] | "IVA" [creq] | "IVD" [creq] | 
                        "CON" [creq] | "HIS" [creq] | "TEL" [creq] | "OTP" [creq]

creq                  = "a" | "i" | "o"

compact-recipient     = "OUR" | "DEL" [creq] | "SAM" [creq] | "UNR" [creq] | 
                        "PUB" [creq] | "OTR" [creq]

compact-retention     = "NOR" | "STP" | "LEG" | "BUS" | "IND"

compact-category      = "PHY" | "ONL" | "UNI" | "PUR" | "FIN" | "COM" | 
                        "NAV" | "INT" | "DEM" | "CNT" | "STA" | "POL" | 
                        "HEA" | "PRE" | "LOC" | "GOV" | "OTC"

compact-test          = "TST"

另外这里还有一个P3P的验证工具：http://www.w3.org/P3P/validator.html，可以验证一下自己设置的P3P是否正确。

这里还有一个老外写的不错的blog，也可以参考一下。http://www.sitepoint.com/article/p3p-cookies-ie6/2

三、

首先介绍第一方Cookie和第三方cookie:
第一方Cookie是来自当前正在查看的网站，或者发送到当前正在查看的网站。

第三方Cookie是来自当前正在查看的网站以外的网站，或者发送到当前正在查看的网站以外的网站。第三方网站通常提供正在查看的网站上的内容。例如，许多站点使用来自第三方网站的广告，或者iframe的别的网站的url，这些第三方的网站可能使用的Cookie。

然后是P3P,Platform for Privacy Preferences:
P3P由万维网协会研制，它为Web用户提供了对自己公开信息的更多的控制。
支持P3P的Web站点可以为浏览者声明他们的隐私策略。
支持P3P的浏览器 则可以将Web站点的策略与用户的隐私偏好进行对比，并为用户提出不匹配的警告。
因此，用户可以被通知有关Web隐私的处理方式。
更详细的说明请看http://www.w3.org/P3P/的介绍

===================================================================================================

理论很简单,而且模式也和大多请求返回状态的SSO差不多.但是有几个地方是要注意一下的.
1.页面里的COOKIE不能是浏览器进程的COOKIE(包括验证票和不设置超时时间的COOKIE),否则跨域会取不到.这点做跨域COOKIE的人比较少提到.不过实际上留意下几家大学做的方案,有细微的提到他们的验证模块里的COOKIE是有设置超时时间的.
2.当利用IFRAME时,记得要在相应的动态页的页头添加一下P3P的信息,否则IE会自觉的把IFRAME框里的COOKIE给阻止掉,产生问题.本身不保存自然就取不到了.这个其实是FRAMESET和COOKIE的问题,用FRAME或者IFRAME都会遇到.
3.测试时输出TRACE,会减少很多测试的工作量.
只需要设置 P3P HTTP Header，在隐含 iframe 里面跨域设置 cookie 就可以成功。他们所用的内容是：
P3P: CP='CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR'
ASP直接在头部加了头部申明，测试有效。
<%Response.AddHeader "P3P", "CP=CAO PSA OUR"%>
php的话，我没去试，应该是如下写法：
header('P3P: CP=CAO PSA OUR');
ASP.NET的话
通过在代码上加Response.AddHeader("P3P", "CP=CAO PSA OUR")或者在Window服务中将ASP.NET State Service 启动。
JSP:
response.setHeader("P3P","CP=CAO PSA OUR")

=============================================================================================================

http://www.xiaonei.com/crossdomain.xml

<!– http://www.xiaonei.com/ –>
?
<cross-domain-policy>
<allow-access-from domain=”*.xiaonei.com”/>
<allow-access-from domain=”xiaonei.com”/>
</cross-domain-policy>

这是很标准的做法，我就让我自己的域以及我的子域来获取数据。

淘宝的：

http://www.taobao.com/crossdomain.xml

<cross-domain-policy>
<allow-access-from domain=”*.taobao.com”/>
<allow-access-from domain=”*.taobao.net”/>
<allow-access-from domain=”*.taobaocdn.com”/>
<allow-access-from domain=”*.allyes.com”/>
</cross-domain-policy>

红色的一行是淘宝的CDN所在的域，所谓内容分发网络。

绿色的一行是淘宝的广告商了，http://www.allyes.com/好耶广告网络，只是不清楚是不是仍然再卖淘宝的广告？

多看几个大网站的crossdomain.xml，也可以知道可能是什么网络广告商给它们在打广告。

比如彭博：http://www.bloomberg.com/crossdomain.xml

<cross-domain-policy>
<allow-access-from domain=”localhost”/>
<allow-access-from domain=”10.16.136.107″/>
<allow-access-from domain=”*.bloomberg.com”/>
<allow-access-from domain=”*.pointroll.com”/>
<allow-access-from domain=”*.pointroll.net”/>
</cross-domain-policy>

红色的就太不专业了，把内部IP都给暴露了。。。。。。

绿色的是彭博的广告商：PointRoll

路透的：

http://www.reuters.com/crossdomain.xml

<cross-domain-policy>
<allow-access-from domain=”*.reuters.com” secure=”false”/>
<allow-access-from domain=”ad.doubleclick.net” secure=”false”/>
<allow-access-from domain=”ad.uk.doubleclick.net” secure=”false”/>
<allow-access-from domain=”m.2mdn.net” secure=”false”/>
<allow-access-from domain=”m2.2mdn.net” secure=”false”/>
</cross-domain-policy>

广告给了doubleclick来做（绿色）

2mdn.net看不懂是干嘛的，大概是个cdn吧。

滥情的facebook:

http://www.facebook.com/crossdomain.xml

<?xml version=”1.0″?>
<!DOCTYPE cross-domain-policy SYSTEM “http://www.adobe.com/xml/dtds/cross-domain-policy.dtd”>
<cross-domain-policy>
<site-control permitted-cross-domain-policies=”master-only” />
<allow-access-from domain=”s-static.facebook.com” />
<allow-access-from domain=”static.facebook.com” />
<allow-access-from domain=”static.api.ak.facebook.com” />
<allow-access-from domain=”*.static.ak.facebook.com” />
<allow-access-from domain=”s-static.thefacebook.com” />
<allow-access-from domain=”static.thefacebook.com” />
<allow-access-from domain=”static.api.ak.thefacebook.com” />
<allow-access-from domain=”*.static.ak.thefacebook.com” />
<allow-access-from domain=”*.static.ak.fbcdn.com” />
<allow-access-from domain=”external.ak.fbcdn.com” />
<allow-access-from domain=”*.static.ak.fbcdn.net” />
<allow-access-from domain=”external.ak.fbcdn.net” />
<allow-access-from domain=”www.facebook.com” />
<allow-access-from domain=”www.new.facebook.com” />
<allow-access-from domain=”register.facebook.com” />
<allow-access-from domain=”login.facebook.com” />
<allow-access-from domain=”ssl.facebook.com” />
<allow-access-from domain=”secure.facebook.com” />
</cross-domain-policy>

这么多！有子域，有CDN，有thefacebook（facebook的旧域名吧？）

还是google的专业：

<?xml version=”1.0″?>
<!DOCTYPE cross-domain-policy SYSTEM “http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd”>
<cross-domain-policy>
<site-control permitted-cross-domain-policies=”by-content-type” />
</cross-domain-policy>

蓝色行的意思是，要符合要求的文件你才能取，不管你是哪来的flash数据请求。符合要求的文档必须满足：Content-Type: text/x-cross-domain-policy

另：

当Flex访问WebService服务时，在本地能够正常访问，当部署到web容器中发布为web服务后，再调用WebServicIE，此时就会被拒绝访问，这就是Flex跨域访问的沙箱问题，
为了解决Flex跨域访问WebService的问题，可采用如下方案：
首先，跨域访问被拒绝是因为提供服务方没有配置安全策略文件，即crossdomain.xml，如果你不想用crossdomain.xml就要用到代理，即自己写一个后台读取webservice，然后提供给自己的flex应用，因为在flashplayer中，要跨域必须要有策略文件。考虑到 flashplayer升级到9.124之后，加强了安全性，之前的crossdomain.xml的写法发生了变化，以下就是该文件的完整写法：
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*" />
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>
表示该服务允许任何外域来访问。
关于crossdomain.xml的放置目录问题，有如下解决方案，可放置在：

1） 如果这个目录是容器的根目录，可以通过以下的url访问crossdomain.xml：

http://localhost:8080/crossdomain.xml 。
2） 如果crossdomain.xml不是放在根目录下，而是在某个webapp下面，在flex中就需要在初始化的时候应用
Security.loadPolicyFile("http:// localhost:8080/aaa /crossdomain.xml");

其中aaa为webapp的名称
这样，外部Flex访问该服务发布的WebService时，flashplayer首先找的就是crossdomain.xml文件，若安全机制设置为允许访问，则访问成功。