msgbartop
很傻很天真的程序员
msgbarbottom

27 九 10 servlet2.5也能用HttpOnly

出来混的,安全很重要!!
收到安全部门的邮件,登录功能存在xss安全漏洞,简单点说就是敏感数据可以被js脚本读到。要用设定cookie的HttpOnly属性,才能降低这种安全风险。百度一下,google HttpOnly,大约描述如下:Servelt3.0有一项新特性,cookie的安全得到提升,提供了HttpOnly属性设置,似的cookie能够根据需要不被js读取。简单,不久在cookie保存的时候,设定一个属性吗?但是,Eclipse告诉我没有该属性。看了下,我用的jar杯具的发现,我们用的是Servlet2.5,不支持HttpOnly。继续google,纠结的是貌似大家实现HttpOnly用的都是Servelt3.0。那么我要实现HttpOnly面临着就是升级Servlet的版本,麻烦接踵而至,Servlet一般是和tomcat一起的,测试的工作量会很大。发现只有tomcat7是Servlet3.0的,现状是公司服务器上的tomcat大多是5的,它们还在等待升级成6呢。为了用HttpOnly升级tomcat到7明显不可能,那么只能另寻它途。在网上看到有tx,介绍可以通过直接写header的方式来保存cookie实现HttpOnly,那么说干就干。第一步先把cookie格式化成一个cookie标准的字符串如(“uc=kbtiao;domain=sina.com.cn;path=/;maxAge=-1;HttpOnly”),第二步通过设置header,response.setHeader(“Set-Cookie”, “uc=kbtiao;domain=sina.com.cn;path=/;maxAge=-1;HttpOnly”),就实现了cookie的HttpOnly。不信,你打开firecookie看看,是不是出现了HttpOnly。
大概的讲完了,下面为了凑字数复制了些关系HttpOnly的介绍:
HttpOnly是微软对cookie做的扩展,该值指定 Cookie 是否可通过客户端脚本访问, 解决用户的cookie可能被盗用的问题,减少跨站脚本攻击 主流的大多数浏览器(firefox,ie6,7,8)已经支持此属性。

01 九 10 p3p java实践

说干就干,要跨域,那么就要有两个域名,本机测试,只要指host就行了。host设置如下:
127.0.0.1 www.a.com
127.0.0.1 www.b.com
接着开始上代码:
http://www.b.com/b.jsp 通过js设置a的cookie
================
<%@ page language="java" contentType="text/html; charset=utf-8"
pageEncoding="utf-8"%>
<%
response.addHeader("Cache-Control","no-cache");
response.addHeader("Expires","Thu,01 Jan 1970 00:00:01 GMT");
cookiev = "test";
%>

================
http://www.a.com/a_setcookie.jsp www.a.com下的cookie设置
================
<%@ page language="java" contentType="text/html; charset=utf-8"
pageEncoding="utf-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 cookiev = request.getParameter("cookiev");
Cookie _cookie = new Cookie("test",cookiev );
_cookie.setMaxAge(30*60*100);
_cookie.setPath("/");
_cookie.setDomain(".a.com");
response.addCookie(_cookie);
%>
================
http://www.a.com/a_getcookie.jsp www.a.com下的cookie遍历
================
<%@ page language="java" contentType="text/html; charset=utf-8"
pageEncoding="utf-8"%>
<%
Cookie cookies[]=request.getCookies();
Cookie sCookie = null;
if(cookies==null){
out.print("none any cookie");
}else{
out.println(cookies.length+"
“);
for(int i=0;i sCookie = cookies[i];
out.println("getVersion==>>>”+sCookie.getVersion()+”\n”);
out.println(“cookiename==>>>”+sCookie.getName()+”->cookievalue==>>>”+sCookie.getValue()+”
“);
}
}
%>
================
花絮:在firefox下可以不用设置response头的p3p申明,而ie是必须的。

01 九 10 p3p那点事情

P3P(Platform for Privacy Preferences Project),一种可以提供这种个人隐私保护策略,并且正在被越来越多的技术人员接受的新技术。 从技术上看,P3P包括了两个组件:一个放在服务器端;另外一个放在客户端,形成一个用户代理。当用户登陆网站的时候,服务器端的组件根据网站的要求,会自动生成XML语言形式的用户个人处理策略,这就像是贴在商店橱窗外的公众告示,而客户端的组件就将这个“公众告示”提供给用户。P3P是一个扩展语法和数据元集,它受RDF(Resource Description Framework,资源描述框架) 语言的规范。它允许用户通过浏览器与网站,通过临时或是成对的ID(TU ID/PU ID)进行协商,以明确可以透露哪些个人信息并且作何用途 。临时ID仅可以持续一个用户对话期,而成对的ID则可以维持多个对话期,这些ID并不带有辅助数据,而且不会被储存。 双方最终通过一个双向的选择达成用户个人隐私策略。P3P并不会使现有的PICS(Platform for Internet Content Selection因特网内容选择平台)标准失效,它仅仅是一个内容标记方案。RDF和XML目前虽然并未被PICS采用,但会在其未来的版本中派上用场。 (以上摘自百度百科)
个人理解,p3p就是允许写第三方cookie的协议,简言之就是跨域写cookie,当然这个还和客户端浏览器的设置有关。现有主流浏览器firefox和ie也有所不同。

30 八 10 Cookie的故事

Cookie指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据(通常经过加密)。
Cookie由服务器端生成,发送给User-Agent(一般是浏览器),通常是浏览器将Cookie的key/value保存到某个目录下的文本文件内,下次请求同一网站时就发送该Cookie给服务器(前提是浏览器设置为启用cookie)。说到浏览器,就不得不提起浏览器家族的恩恩怨怨了。前端做开发的时候,为浏览器兼容苦恼着,后端又何尝不是呢。当我们在处理cookie是否注意过,ie和firefox的处理方式是不一样的。
那是某天晚上,俺在查一个bug,看了程序逻辑,貌似没有问题。俺质疑cookie存在问题,找到方向了,就开始挖据吧。不停的通过ie访问,firefox访问,观察彼此输出的cookie信息的内容。慢,貌似他们前期是相同的,当我进行过一次cookie重置后,貌似有所不同(重置:就是把cookie的maxAge=0)。firefox对maxAge的处理是当maxAge=0时,该cookie不在出现在cookie列表中,而ie是继续存在cookie列表中一个被重置的cookie值。这样就导致,我们在回复cookie是不但要判断cookie获取是否为空,还是判断cookie的内容是否为空了。呜呼哀哉,原来一直以为浏览器会影响前端,没有想到它对后端的影响也不少啊。

29 八 10 Firefox升级后cookie失效(丢失)的终极解决方案

每次升级Firefox,一些论坛的Cookie就会失效,需要重新登录。这是因为,很多论坛的Cookie是绑定User Agent的,一旦User Agent改变(Firefox每次升级,User Agent就会改变),Cookie就会失效。这个问题,可以通过固定Firefox的User Agent的方法解决这个问题,方法如下:
在地址栏输入 about:config 回车,然后在下面的窗口点击鼠标右键,选择“新建”->“字符串”,出来的对 话框中输入
[java]general.useragent.override[/java]
,按确定后,会让你输入刚才那个选项的值,也就是你 要设定的User Agent。比如,我的系统是Windows 2003,Firefox 是3.0b2pre,我指定的User Agent是:
[java]Mozilla/5.0 (Windows; U; Windows NT 5.2; zh-CN; rv:1.9) Gecko/Firefox/3.0[/java]
如果你用的是Firefox 2.0.0.x系列,Windows是XP,那么可以设成:
[java]Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1) Gecko/Firefox/2.0[/java]
这个修改立刻生效,从About对话框中就可以看的 出来。设定完后,可以到下面这个网页查看自己的 User Agent 设置的是否正确: http://www.useragentstring.com/
当然,做了上面的设定以后,因为User Agent改变了,所有绑定 User Agent 的论坛,都会要求你重新登录一次。不过,只要重新登录一次后,以后升级Firefox时就不用再登录了(除非你将原来的配置文件夹删除),cookie会 一直有效,直到真的过期为止。

21 八 10 慎用Html的DOCTYPE

话说我终于要把一个“旧”系统(比我的工龄还老)维护工作移交给一个新同事去做,但是日常的发布还是走的我流程。因需求方要求,我增加一个新的功能,反正熟门熟路,那个同事不在我就自己动手干吧。我用了一个以前写的时间控件,怎么折腾总是不能成功,看了一遍有一遍的代码,还是发现不了任何问题。同样的控件,同样的环境,同样的使用方法,就是不同的页面。感觉糗大了,本来以为很简单的东西 ,被我折腾了一两个小时。偶然的一眼,我发现了两个页面最大的不同之处,新的页面是有<!DOCTYPE> 声明的,老的页面是没有的。莫非这个就是罪魁祸首,说干就干,我动手把新页面上的<!DOCTYPE> 声明删除掉,没想到控件就可以用了。问题解决了,但是解决的有点莫名其妙,因为平时对html标准并不关注。于是,就开始baidu-google。以下是个人的一些小结:

1、<!DOCTYPE>不能随便用

2、为了兼容老的代码,<!DOCTYPE>还是不要轻易使用

3、俺们的老代码该升级换代了

注:<!DOCTYPE>位于文档中的最前面的位置,用于可告知浏览器文档使用哪种 HTML 或 XHTML 规范。该标签可声明三种 DTD 类型,分别表示严格版本、过渡版本以及基于框架的 HTML 文档。

02 七 10 解决window.close()在IE7下弹出对话框的问题

window.opener=null;
window.open(”,’_self’,”);
window.close();

02 七 10 http_load学习心得

测试网站每秒所能承受的平均访问量(吞吐量)
http_load -parallel 5 -fetches 1000 urls.txt
这段命令行是同时使用5个进程,随机访问urls.txt中的网址列表,总共访问1000次。运行之后的结果:
1000 fetches, 5 max parallel, 6e+06 bytes, in 58.1026 seconds
6000 mean bytes/connection
17.2109 fetches/sec, 103266 bytes/sec
msecs/connect: 0.403263 mean, 68.603 max, 0.194 min
msecs/first-response: 284.133 mean, 5410.13 max, 55.735 min
HTTP response codes:
code 200 — 1000
从上面的运行结果来看,目标网站仅仅能够承受每秒17次访问,不够强壮。
测试网站是否能承受住预期的访问压力(
http_load -rate 2 -seconds 300 urls.txt
在300秒内保持一定的频率访问目标url。
注:
urls.txt保存要访问的url列表,每行一个
不要测试上线之后的网站,压垮了可不好玩
例如:
1.http_load -parallel 5 -fetches 1000 urls.txt
2.http_load -rate 2 -seconds 300 urls.txt
3. http_load -p 30 -s 60   urllist.txt
4. http_load -parallel 50 -s 10 urls.txt
这段命令行是同时使用50个进程,随机访问urls.txt中的网址列表,总共访问10秒。

参数说明:
-parallel 简写-p :含义是并发的用户进程数。
-fetches 简写-f :含义是总计的访问次数
-rate    简写-r :含义是每秒的访问频率
-seconds简写-s :含义是总计的访问时间
参数是可以自由组合的,参数之间的选择并没有什么限制。
urls.txt保存要访问的url列表,
url 是你要访问的网址名,参数可以是单个的网址也可以是包含网址的文件。 文件格式是每行一个URL,URL最好超过50-100个测试效果比较好. 文件格式如下

http://iceskysl.1sters.com/?action=show&id=336

http://iceskysl.1sters.com/?action=show&id=335

http://iceskysl.1sters.com/?action=show&id=332

http://iceskysl.1sters.com/?action=show&id=32

参数了解了,我们来运行一条命令, 来看看它的返回结果
命令:% ./http_load -rate 5 -seconds 10 urls
命令解释: 执行一个持续时间为10秒的测试,每秒的访问频率为5次。
49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds
5916 mean bytes/connection
4.89274 fetches/sec, 28945.5 bytes/sec (重要性能指标吞吐量)
msecs/connect: 28.8932 mean, 44.243 max, 24.488 min(重要指标响应时间)
msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
HTTP response codes:
code 200 — 49
结果分析:
1.49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds
说明在上面的测试中运行了49个请求,最大的并发进程数是2,总计传输的数据是289884bytes,运行的时间是10.0148秒
2.5916 mean bytes/connection
说明每一连接平均传输的数据量289884/49=5916
3.4.89274 fetches/sec, 28945.5 bytes/sec (吞吐量: 单位时间完成请求数)
说明每秒的响应请求为4.89274,每秒传递的数据为28945.5 bytes/sec
这个值得是根据 49 fetches / 10.0148 seconds 秒计算出来的
4.msecs/connect: 28.8932 mean, 44.243 max, 24.488 min (响应时间: 每次请求需要的时间, 平均, 最大, 最小)
说明每连接的平均响应时间是28.8932 msecs,最大的响应时间44.243 msecs,最小的响应时间24.488 msecs
5.msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
6、HTTP response codes: code 200 — 49
说明打开响应页面的类型,如果403的类型过多,那可能要注意是否系统遇到了瓶颈。
特殊说明:这里,我们一般会关注到的指标是fetches/sec、msecs/connect
他们分别对应的常用性能指标参数
Qpt-每秒响应用户数和response time,每连接响应用户时间。
测试的结果主要也是看这两个值。
当 然仅有这两个指标并不能完成对性能的分析,我们还需要对服务器的cpu、memory进行分析,才能得出结论,另外,测试结果中主要的指标是 fetches/sec 这个选项,即服务器每秒能够响应的查询次数,用这个指标来衡量性能。似乎比 apache的ab准确率要高一些,也更有说服力一些。

http_load测试参数比较
./http_load -parallel 200 -seconds 10 urls
按照固定时间来结束测试,这样可以比较相同时间内被测服务器的响应速度.
./http_load -parallel 200 -fetches 1000 urls
按照固定申请数来测试,这样可以比较相同访问量下返回的响应速度.
虽然两者都可以获取到服务器的响应速度
但是使用fetches更容易让被测服务器收到压力
由于seconds控制测试时间,很有可能在短时间内测试客户端并没有发起足够数量的请求
而服务端在收到足够压力之前,测试就已经结束了.
有一些情况,诸如内存泄漏以及资源回收不利或者对后面的响应速度越来越慢等情况
在这种测试条件下不容易发生
而使用fetchs,能够让客户端保证确定请求数的全部处理.
使用时间作为控制参数
会由于测试人员不够耐心而人为将seconds参数设置过小
导致测试结果失去意义
所以,最后建议使用fetches作为测试参数.用以作为基准进行比较

02 七 10 http_load的使用

记得前些天介绍了一个幻灯——Getting Rich with PHP 5(IE之外的浏览器可看,见用php5来赚大钱),这个幻灯向我们展示了php程序优化的一些技巧,其中命令行工具http_load给我留下很深的印象,这工具看上去和apache的ab很相似,用来做网站的压力测试。昨天在服务器上安装http_load并试用了一段时间,下面是我的一点学习心得。

测试网站每秒所能承受的平均访问量
http_load -parallel 5 -fetches 1000 urls.txt
这段命令行是同时使用5个进程,随机访问urls.txt中的网址列表,总共访问1000次。运行之后的结果:

1000 fetches, 5 max parallel, 6e+06 bytes, in 58.1026 seconds
6000 mean bytes/connection
17.2109 fetches/sec, 103266 bytes/sec
msecs/connect: 0.403263 mean, 68.603 max, 0.194 min
msecs/first-response: 284.133 mean, 5410.13 max, 55.735 min
HTTP response codes:
code 200 — 1000

从上面的运行结果来看,目标网站仅仅能够承受每秒17次访问,不够强壮。

测试网站是否能承受住预期的访问压力
http_load -rate 2 -seconds 300 urls.txt
在300秒内保持一定的频率访问目标url。

注:

•urls.txt保存要访问的url列表,每行一个
•不要测试上线之后的网站,压垮了可不好玩

02 七 10 使用http_load测试动态页面的性能遇到的问题及解决办法

使用http_load在测试过程中遇到了一个非常棘手的问题,就是页面内容是动态变化的——而http_load在处理时会去关注每次访问同一个URL返回结果(即字节数)是否一致,若不一致就会抛出Byte Count Wrong。但对于静态页面出现这个提示,说明系统不能承受如此大的压力(也可能是其他原因,在这里我只说这一点);但对于动态页面,通过这种进行判断就有失准确性了……
通过自己观察,并与开发沟通发现页面的动态变化是有一定规律的——只是一少部分内容发生变化(换句话说,就是两次返回的字节数应该相差不是非常大)。如果能找到“两次”访问返回的字节数,并经过对比如果相差不大(开发认为是正常的),那可以说明返回的页面就是正常的(此时就可以忽略掉“byte count wrong”);如果相差很大(开发也认为是非正常的),那可以说明返回的页面有误)。
如果能让http_load中记录的“日志”中体现出两次返回的字节数就好了……于是开始研究http_load.c(源码),终于找到了一个可以添加的入口,问题解决!以上的“如果”能实现了!
修改的代码如下:
【原来的】
“stderr, “%s: byte count wrong”, urls[url_num].url_str );”
【修改的】
“stderr, “%s: byte count wrong: first=%d,cur=%d\n”, urls[url_num].url_str,urls[url_num].bytes,connections[cnum].bytes );”

Analytics Plugin created by Web Hosting

普人特福的博客cnzz&51la for wordpress,cnzz for wordpress,51la for wordpress