谨防Java网络编程“陷阱”

时间:2010-01-16 09:11:28   来源:第二电脑网  作者:第二电脑网

  第二电脑网导读:,却发现在购物车里提交了两次结果。千万别以为是自己眼花了,或者是遭病毒袭击了,这些就是我们编程中容易碰到的“陷阱”。下面我们就这两个问题分别进行讨论。 翻页中的“陷阱”翻页有两种常用的实现方式:基于session的翻页和基于hidden的翻页。 1.将页号信息保存在session中 这是最常使用的方法。这种方法的初衷是利用session在页面之间传递信息,即将页号信息保存在session变量中。这...
  正文:

大多数做过基于Web的Java编程的人都做过“翻页”、“提交”这种比较基础的工作。这些网络编程中不可缺少的步骤,通常都很容易实现。但不知你有没有过这样的经历:在一些特殊情况下,翻页出现了混乱,明明下一页应该是第5页,却翻到第3页;明明只提交了一次,却发现在购物车里提交了两次结果。千万别以为是自己眼花了,或者是遭病毒袭击了,这些就是我们编程中容易碰到的“陷阱”。下面我们就这两个问题分别进行讨论。 翻页中的“陷阱”翻页有两种常用的实现方式:基于session的翻页和基于hidden的翻页。 1.将页号信息保存在session中 这是最常使用的方法。这种方法的初衷是利用session在页面之间传递信息,即将页号信息保存在session变量中。这样,上下翻页时,只需从session中取出当前页号,并进行相应的处理。当有不同的查询页面指向同一个结果页面时,可在不同的查询页面内将session内的页号值重置,可较好地实现复用。 很多人习惯采用如下实现方法: 假设有两个查询页面time.jsp和place.jsp,分别以时间和地点为查询条件,结果指向同一个显示页面result.jsp。在time.jsp和place.jsp中均有这样的语句:


<jsp:useBean id=“page” class=“Page” scope=“session”></jsp:useBean><%page.setPageNum(1);%>
在result.jsp中有这样的语句:
下一页:<%page.nextPage();%>上一页:<%page.previousPage();%>
在类page中,有这样的代码
private int pageNum;public void setPageNum(int i){  pageNum = i;}public void previousPage(){  pageNum --1;}public void nextPage(){  pageNum ++;}
现在来看一看“陷阱”是怎么产生的。 当以时间为查询条件时,下翻到第5页,将此窗口命名为窗口1。此时重新打开一个窗口(Ctrl+N方式),以地点为查询条件,下翻到第3页,将此窗口命名为窗口2。到目前为止,一切正常。但请注意:当再回到窗口1,并向下翻时,问题便出现了——原本应该是第6页,现在显示的却是第4页。 为什么呢?原因很简单:两个窗口共享一个session值,当窗口2切换回窗口1时,窗口1引用的pageNum值已被窗口2改变了。 由此可以发现,session在不同页面之间共享信息固然很有用,但必须小心使用,否则会制造出一些隐藏很深的错误。 2.通过URL再次传递页号信息 先来看一下具体的实现方法:例子仍基于上述情况。首先,在time.jsp和place.jsp中,删除对JavaBean的调用。分别在两个文件的提交url后追加页号信息,例如,在time.jsp中,加入代码result.jsp?date=‘20021010’&&pageNum=1;在place.jsp中,加入代码result.jsp?place=‘bj’&&pageNum=1。 其次,在result.jsp中做如下设置:将url中所有变量以hidden的形式重新写入form中。下面为其代码实例:
<form name=“fm” method=“get” action=“result.jsp”>  <table>   <tr>    <input type=‘hidden’ name=‘date’ value=<%=request.getParameter(“date”)%>>        <input type=‘hidden’ name=‘place’ value=<%=request.getParameter(“place”)%>>    <input type=‘hidden’ name=‘pageNum’  value=<%=request.getParameter(“pageNum”)%>>  </tr></table></form>
这种方法看似愚笨,让人有多此一举的感觉,但事实上它却是出现漏洞最少的一种方法。这样以来,每个结果页面都有自己独立的页号信息,不存在干扰情况,从而避开了“陷阱”。 重复提交中的“陷阱”当我们进行网上购物时,在选择了满意的商品后,就要进行提交操作。如果网速较慢或有其它因素影响,就会迟迟不出结果。于是我们常常回退或停止,然后再次提交。这次很快有了响应,但奇怪的是,明明只提交一次,购物车中的商品却是双份的。产生原因是这样的:当因为迟迟不响应而回退时,在服务器端有两种可能,一种是提交已经得到了处理,数据库中已有了相应记录,但结果页面没有显示出来;另一种是提交还未得到处理,这种没有任何问题。 针对这个现象,解决办法是引入同步机制(SynId)。指导思想就是,为每一个页面编号,并在客户端和服务器端各产生一个副本,每次通过比较两端的编号是否一致,达到同步的目的。首先,由服务器产生这个编号,发送到客户端。这样这个编号在服务器和客户端各有一个副本。当客户提交页面时,服务器首先比较两个编号是否一致。如果一致,则处理提交,并产生一个新的编号,返回给客户端。此时如果客户回退并再次提交,客户端是旧编号,服务器端是新编号,显然不一致,因此服务器将判定这是一次重复提交,不予受理。 实现过程如下(如图所示):
来源:http://www.002pc.com/master/College/Programming/JSP/11931.html

收藏到:

关于《谨防Java网络编程“陷阱”》文章的评论

共有 0 位网友发表了评论 此处只显示部分留言 点击查看完整评论页面

随机文章

    SQL Error: select * from ***_ecms_article where classid='85' and checked=1 order by rand() limit 10

顶出来的热门

    SQL Error: select * from ***_ecms_article where classid='85' and checked=1 order by diggtop desc,id desc limit 10
站内搜索: 高级搜索

热门搜索: Windows style 系统 tr IP QQ CPU 安装 function 注册 if td