邵珠庆の日记 生命只有一次,你可以用它来做很多伟大的事情–Make the world a little better and easier


171月/123

浏览器差异 window.open

发布在 邵珠庆

w3help的测试,和我的测试相互补充,应该比较完整了.悲剧的是我做完测试后,和莫提了一嘴,他告诉我w3help有啊. 我累个去.咋不早说.我可以省不少事呢.
 
建议先看看w3help的.内容比较详细.尤其是据说 window.open,这种宿主方法.居然,可能在将来被html5所统一.期待啊.
 

浏览器实现差异:

     
           .一个open的窗口被拦截后, Opera11-  ,Chrome11- 仍然会有窗口句柄. 而Safari是undefined ,IE  Firefox 则是 null. 而Opera,Chrome拦截掉窗口后.这个窗口的window.closed属性为false.
           (所以在不考虑Opera和Chrome的情况下.可以用 !!win 来判断窗口是否被拦截. 而win.closed没有更大的意义)

          .sougou高速浏览器2.1+ IE内核下,会无视该弹窗是否为响应用户鼠标操作的回调(a 和 input button 以及button等点击类交互标签是不被拦截的).而一律强制拦截弹窗. 而且用a标签的click()也会被拦截.(好在,IE内核下,被拦截后,win 都是null.可以检测出来,用跳转代替,遗憾的是chromium内核下同chrome一样.被拦截时,无法检测.要检测chrome,opera的弹出,比较麻烦,弹一个about:blank,Opear检测documentElement是否存在,chrome则需要检测documentElement.clientWidth === 0)
          .各个浏览器使用window.open,第三参数效果:(应注意,如果连续写多个参数,应以 ","号分隔.如果其中某个参数名有错误,则可能导致整个第三参数在,Chrome和IE浏览器中失效)
浏览器 无参数 width,height left,top toolbar location
Directories
Status
Menubar
Scrollbar
Resizable
screenX,screenY
FullScreen
期待结果 有标签的 标签
无标签的 弹窗
尽量按指定
宽高弹窗
语义冲突的参数
相对parent页
left ,top位置
默认 无工具栏
yes 有工具栏
no 无工具栏
默认 有(r)
yes   有(w)
no  无
(r)只读,(w)可写
这玩意到底
是神马?
只有IE6支持
无期待结果
默认 无
yes 有
no 无
垃圾参数
无视.
只对早期
ie有效
默认auto
yes auto
no 无
默认 是
yes 是
no 否

真正语义上的参数
相对屏幕坐标
全屏显示
IE 6 弹窗

7-8 弹窗

9 标签

全部 ok (注1) 全部

   默认无

   yes 有
   no  无

 

6
  默认 无
  yes 有(w)
(toolbar也有了)

  no 无

7,8,9
  默认 有(r)
  yes 有(w)
  no 有(r)
 

6
 toolbar去掉
 location部分

7,8,9不支持

6,7,8
无视参数
始终 有

9
 默认 无
 yes 有
 no 无

  全部
 无视参数
 始终 无
全部
 默认 否
 yes 是
 no 否
不支持 全部
 支持
Chrome 全部 标签 全部 ok 全部相对 

父页面

left,top

不支持此参数
弹窗木有工具栏
不支持此参数
始终有,且只读
不支持 无status bar   1
 无视参数
 始终 无 

2+ 
 默认 auto
 yes auto
 no auto

不支持此
参数,一律
可缩放
完全 ok  不支持
FireFox 1, 1.5 弹窗

2.0+ 标签

全部 ok

全部
 left 相对父页面left

 
 top 相对屏 幕

   默认无

   yes 有
   no  无

1, 1.5, 2 
 默认 无
 yes 有(r)
 no 无

3+
 无视参数
 始终有(r)

不支持
无视参数
始终 有
 
无视参数
始终 无
2- 
 默认 否
 yes 是
 no 否

3+
 不支持此
参数,一律
可缩放.

完全 ok
3.6-
 不支持

4
 支持
 

Safari 3+ 弹窗
(Safari5 偏好设置
,在标签中打开新
页面, 选项有-总是
,永不,自动.默认是
永不.导致此问题.)
3+ ok
全部
   left 相对
父页面
(但当父窗体left
位置导致新窗体
全部显示时,则
新窗体left,相对
为0,与ie7有些
相似)

   top 相对屏幕
   默认无

   yes 有
   no  无

 默认 无
 yes  有(w)(但
工具栏也有了)

 no 无
不支持
 默认 无
 yes 有
 no 无
 
无视参数
始终 无
不支持此
参数,一律
可缩放
完全 ok
不支持
Opera 9.2+ 弹窗 9.2 tab

9.6+ 
标签(有宽高,可拖
拽.但无法离开父
窗口)
9.6+ 
相对父页面
的left,top

9.2 标签
9.2 tab

9.6+ 因其本质
是tab所以无视
此参数.一律无
toolbar

9.2 tab

9.6+ 因其本质
是tab所以无视
此参数.共享
location
不支持
9.2 tab

9.6+ 因其本质
是tab所以无视
此参数.共享
statusbar
 
无视参数
始终 无
不支持此
参数,一律
可缩放
不支持
不支持
                         
360安全 3.3+ 标签

3.612 弹窗

3.612 弹窗(无视
宽高参数parent
页面多大新弹窗
就多大)

其他版本 标签

3.612 left top
和parent页面
有关,但位置算
法很混乱.

其他版本 标签
3.612 弹窗无视
一切参数.显示
一个完整窗口

其他版本 标签
.. .. .. .. .. .. .. ..
360高速 两种内核都 标签 IE内核 标签

chromium都 ok

chromium 
同chrome

其他内核 标签
..
.. .. .. .. .. .. .. ..
搜狗高速 两种内核都 标签
两种内核都 标签
标签
.. .. .. .. .. .. .. .. ..
TT 标签 标签
标签
.. .. .. .. .. .. .. .. ..
QQ5 两种内核都 标签
两种内核都 标签
标签
.. .. .. .. .. .. .. .. ..
Maxthon2.5 标签
标签
标签
.. .. .. .. .. .. .. .. ..
Maxthon3 两种内核都 标签 两种内核都 标签
标签
.. .. .. .. .. .. .. .. ..
世界之窗 标签
标签
标签
.. .. .. .. .. .. .. .. ..
MyIe 标签
标签
标签
.. .. .. .. .. .. .. .. ..
 
ps:表中测试,有冲突的一些项目就不记录详细数据了,地方有限.意义不大.比如 location  = no , toolbar=yes 或反之. Safari下 是只有有一个是yes就都会有. 而ie6则很有趣.会分的很细.
 

第二参数target(name)相关: 

    用途:          

      .参考 target =_self , _blank , _top , _parent , target ,还有传说中的_newtab ,神马的.据说可以让ie7+ 不弹窗而是打开新标签.但是我测试失败了.求高人指点.     
   
      .为窗口对象设置name属性-window.name.        
 
      .所以对于同一个浏览器来说,各个窗口的name是具备唯一性的.(opera9.6+ 开始有些特殊.)    
     
 
      .也就是说, 如果已经存在一个窗口对象的name为abc.则后面再次window.open(url,'acb')的话.那么只会操作这个窗体对象的url,导致跳 转或reload(false).无论它是iframe还是一个被open的独立的窗体                            
 

     差异:                                      

      .IE下target(name)的值不能包含如.、& 等特殊字符.否则会报参数错误.(解决办法.避免使用包含特殊字符的字符串,作为name的值)

 

      .IE下name的值为null 或 undefined时,行为与其他浏览器有差异. 等价于 'null' 或 'undefined' .在期望打开多个窗口,又想设置其他窗口参数时,参数设置此2值.会被视为有效的name值. (解决办法,使用 '' 空字符,或'_blank'代替 null 或 undefined. 建议用优先考虑空字符,因为某些浏览器的早期版本不支持 _blank) 

      .一个已经open的窗口,再次使用相同name,进行window.open操作时,个别浏览器可能不会保证该窗体的可见性(在最上层显示).比如Firefox在最小化某窗口后.(解决办法:可以借助win.focus() 操作强制该窗口在最上层显示.)

      .Opera,Chrome 下,如果一个iframe的id,与window.open的第二参数name同名.也具备同样效果. 其他浏览器则无此现象.

      .Opera9.6+ ,如果在另一个iframe内调用其self.open的第二参数name与其他iframe的name或id同名,则仍然会重新打开一个窗口. 而不是去操作该iframe.其他浏览器则无此问题


 

 
注1
IE6. left 一个奇怪值,top 相对屏幕

IE7. left 相对的位置,总是相对非最大化时,父页的left+10px左右偏移.(就是非最大化时,显示在哪,最大化时,就显示在哪.但并不总是相对非最大化时的父窗口left,比如在父窗口left很靠右的情况下,则其会新窗口会变成相对屏幕来显示)

  top 相对屏幕

IE8. left,top全部相对屏幕

IE9. left 同IE6类似top 相对屏幕总是0

171月/1222

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" 方式去预读一次. 如果你有这个想法。还是早早放弃的好.