前两天帮同事处理一个 js 跨域问题,使用 jsonp 跨域提交用户名密码请求,实现自动登录第三方网站,即 SSO(single-sign-on) 单点登录,一处登录处处登录。在 Chrome 下没问题,IE 却不行。查看 HTTP 的几个来回,发现登录请求是成功的,问题出在第三方网站返回的 cookie (session id) IE 并没有接受,下一次发送请求时根本没有带上 cookie,说明之前的 Set-Cookie 指令没有效果,所以怎么也登录不了。查了一下,有人使用 iframe 内嵌网页的形式,也遇到了 IE 下不能设置 cookie 的情况。
如果在“Internet选项”中把“隐私”级别设置为低,或者把第三方域名列入“可信站点”就没问题了。但是我们不可能让每个用户去更改 IE 设定吧?这是一个很常遇到的场景,肯定有别的解决办法。
浏览器的第三方 cookie 限制
所谓第三方 cookie,就是说你访问网页 A,却接收到域名 B 的 cookie 设定指令。这可能是由于网页 A 请求或链接了 B 的网页,比如上面提到的 iframe 以及 jsonp。
我查到了各个浏览器对于跨域的处理规则,可以看到第三方 cookie ,IE 在默认设置中是做了限制的。
IE | FIREFOX | CHROME | SAFARI | OPERA | |
---|---|---|---|---|---|
限制第三方coookie | 是 | 否 | 否 | 是 | 否 |
要解决这个问题,有 2 种方法,一个就是上面说到的调整 IE 设置,将第三方域名加入到可信网站列表中;另一个方法,就是 P3P 了。
P3P?
P3P 全称 Platform for Privacy Preferences,隐私设定平台规范。这个规范极其复杂,若要讲清楚,天都黑了一半。简言之,就是网站向浏览器声明自己的隐私政策,比如网站是否搜集访问者的个人信息,设置 cookie 的用途等等。浏览器会依据设置,决定在第三方请求的条件下是否接受网站的 cookie。
完整地部署 P3P 包括设立隐私政策文件(policy.html)、原则档(policy.xml)、参考档(p3p.xml),有兴趣详细了解的可以参考 MSDN 中关于部署 P3P 的文章。
这搞得太复杂了,我只是想在公司内部做各个管理系统的单点登录而已。好在还是有比较简单的方法的,就是发送 P3P 相关的 HTTP header。
ASP.NET:
HttpContext.Current.Response.AddHeader("p3p", "CP=\"IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\""); |
PHP:
|
JSP:
response.setHeader("P3P","CP='IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT'"); |
好吧,这些 IDC DSP 什么的是啥意思啊?
这些标签就是 P3P 所规定的了,例如 NOI 表示不搜集可识别用户的资料,ADM 表示信息搜集会用于网站管理……查看完整清单,中文简要清单。
浏览器会根据这些标签决定是否接受 cookie,根据测试结果,加上 NOI 最省事,一个就够了。不过网站一般很难做到 NOI,除非永远匿名,“登录”功能可能就违背了NOI。理论上讲,标签应该真实地反映网站的信息搜集行为,若声明的隐私政策与实际行为不符,是会要负法律责任的。Stackoverflow 有篇讨论提出了法律相关议题,可以参考。
除了传送 P3P http header,还可以通过 HTML meta 标签,或者 设定 IIS 服务器 来声明 P3P。
PS:查看好几篇类似JSP中使用P3P解决跨域的方法,发现P3P的值不太一样,但在IE9下都是正确的,在此记录一下
response.setHeader("P3P","CP='IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT'");
response.setHeader("P3P","CP=\"NON DSP COR CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa CONa HISa TELa OTPa OUR UNRa IND UNI COM NAV INT DEM CNT PRE LOC\"");
response.setHeader("P3P","CP=CAO PSA OUR");
response.setHeader("P3P","CP='CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR'");
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
从技术角度看,使 Web站点支持 P3P 是一个很容易的过程。但是,它要求网络运营商在审视数据处理方式时比以前更加仔细,并要求他们协调域内各个主机上的策略和处理方式。以下是如何使站点支持P3P 技术的具体步骤。
1. 创建一个隐私策略。
2. 分析 cookie 的使用情况以及您的站点上的第三方内容。
3. 确定要对整个站点应用一个P3P策略还是对站点的不同部分应用不同的P3P 策略。
4. 为站点创建一个或几个 P3P 策略。
5. 为站点创建一个策略引用文件。
6. 为 P3P 配置服务器。
7. 测试站点,以确定它确实支持 P3P。
● 如何与拥有该站点的公司、组织或个人进行联系的信息。
● 用户是否可以查找该站点的数据库中保存了自己的哪些个人信息。
● 如何解决与站点之间有关隐私的纠纷(如客户服务台、隐私封印以及与隐私相关的法律等)。
● 所收集数据的种类。
● 所收集数据的使用方式,以及用户是否能选择接受或拒绝这些用途。
● 信息是否会被共享以及何时被共享,用户是否有选择的权力。
● 对所收集的用户信息进行定期清除的策略。
有很多软件工具可以帮助Web站点开发人员开发支持P3P的站点。
简洁策略对应的 HTTP Response Header :
compact-policy-field = `CP="` compact-policy `"`
compact-policy = compact-token *(" " compact-token)
compact-token = compact-access |
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] |
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" |
compact-test = "TST"
我们常用的简洁策略的 P3P头为 - P3P : CP=CAO PSA OUR (其实, CP=. 就可以了.或者其他任何值都是可以的)分别对应了 :
compact-access(访问) : CAO - contact-and-other
compact-purpose(目的) : PSA - pseudo-analysis .这个就不放解释了,字面意思很明显, 目的就是做身份验证、分析
compact-recipient(受体) : OUR - ours
ps : 其他项就不列举,基于浏览器中只有IE支持.(chrome 部分支持).这一事实.深入研究没有必要. 如果你有兴趣,可以去相关链接查看文档.
已测知的问题:
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();}}
默认不禁止第三方cookie的浏览器测试:
浏览器 | 默认允许第三方Cookie | 是否支持P3P | 禁止第三方Cookie后,配置P3P简明策略头的效果 | 补充 |
IE6 | 否 | 是 | HTTP可读写Cookie (第二次.直接Cache.也不行.除非第一次非Cache并读到p3p头.后面我会提到解决方案.) | 避免JS的写操作 |
IE7-IE9 | 否 | 是 | HTTP、JS,可随意读写. | - |
FireFox | 是 | 否 | HTTP、JS都不可读写 | - |
Chrome | 是 | 部分支持,趋势-否 | 趋势为HTTP、JS可读不可写. | - |
Safari | 否 | 否 | HTTP、JS可读不可写 | 借助Post提交表单,实现写操作. |
Opera | 是 | 否 | JS可读写 HTTP可读不可写. | - |
建议:
最后:
如果你非要用在ie6下,用js写cookie. 那么有一个很悲剧的做法.. 服务器端给资源配置可缓存.(包括反向代理和客户端.) 然后想办法在IE6的时候刷新一次页面.这样就ok了. 刷新时一定要用 location.reload(false) 即先忽略客户端缓存.尝试304服务器端校验客户端缓存可靠性..这样做的好处是.即保证了 cookie的写入性. 又保证,如果页面是静态资源.则反向代理的可用性.. 否则还是直接用动态资源,http方式去写好了. 需要注意的是.除了页面刷新.譬如其他方式加载页面资源.试图通过预读其p3p简洁策略头.是无效的. 比如 用 script type="text/c" 方式去预读一次. 如果你有这个想法。还是早早放弃的好.
参考链接:
http://blog.darkthread.net/post-2011-10-27-p3p-header-and-iframe-session.aspx
http://www.lovelucy.info/ie-accept-third-party-cookie.html
http://blog.csdn.net/cuihaiyang/article/details/8106651
http://www.cnblogs.com/_franky/archive/2011/03/16/1985954.html