谨防Java网络编程“陷阱”

　　大多数做过基于Web的Java编程的人都做过“翻页”、“提交”这种比较基本的工作。这些网络编程中不可缺少的步骤，通常都很容易实现。但不知你有没有过这样的经历：在一些特殊情况下，翻页出现了混乱，明明下一页应该是第5页，却翻到第3页；明明只提交了一次，却发现在购物车里提交了两次结果。千万别以为是自己眼花了，或者是遭病毒袭击了，这些就是我们编程中容易碰到的“陷阱”。下面我们就这两个问题分别进行讨论。
　　
　　翻页中的“陷阱”
　　
　　翻页有两种常用的实现方式：基于session的翻页和基于hidden的翻页。
　　
　　1.将页号信息保存在session中
　　
　　这是最常使用的方法。这种方法的初衷是利用session在页面之间传递信息，即将页号信息保存在session变量中。这样，上下翻页时，只需从session中取出当前页号，并进行相应的处理。当有不同的查询页面指向同一个结果页面时，可在不同的查询页面内将session内的页号值重置，可较好地实现复用。
　　
　　很多人习惯采用如下实现方法：
　　
　　假设有两个查询页面time.jsp和place.jsp，分别以时间和地点为查询条件，结果指向同一个显示页面result.jsp。在time.jsp和place.jsp中均有这样的语句：
　　
　　
　　
　　<%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中。下面为其代码实例：
　　
　　　
　　
　　这种方法看似愚笨，让人有多此一举的感觉，但事实上它却是出现漏洞最少的一种方法。这样以来，每个结果页面都有自己独立的页号信息，不存在干扰情况，从而避开了“陷阱”。
　　
　　
　　重复提交中的“陷阱”
　　
　　
　　当我们进行网上购物时，在选择了满意的商品后，就要进行提交操作。如果网速较慢或有其它因素影响，就会迟迟不出结果。于是我们常常回退或停止，然后再次提交。这次很快有了响应，但奇怪的是，明明只提交一次，购物车中的商品却是双份的。产生原因是这样的：当因为迟迟不响应而回退时，在服务器端有两种可能，一种是提交已经得到了处理，数据库中已有了相应记录，但结果页面没有显示出来；另一种是提交还未得到处理，这种没有任何问题。
　　
　　针对这个现象，解决办法是引入同步机制（SynId）。指导思想就是，为每一个页面编号，并在客户端和服务器端各产生一个副本，每次通过比较两端的编号是否一致，达到同步的目的。首先，由服务器产生这个编号，发送到客户端。这样这个编号在服务器和客户端各有一个副本。当客户提交页面时，服务器首先比较两个编号是否一致。如果一致，则处理提交，并产生一个新的编号，返回给客户端。此时如果客户回退并再次提交，客户端是旧编号，服务器端是新编号，显然不一致，因此服务器将判定这是一次重复提交，不予受理。
　　
　　实现过程如下（如图所示）：
　　
　　图 同步机制实现过程
　　
　　
　　当用户首次购物时，发出购物请求，完成步骤1——在服务器端产生一个同步环，保存在session中；客户在购物页面完成步骤2——将同步环保存在客户端的hidden中；客户选购完毕，提交请求，步骤3启动——服务器比较session中的同步环和客户提交的是否一致；如果一致，服务器处理请求，完成步骤4；然后进行步骤5——产生一个新的同步环，并将结果页面返回给客户。如果此时客户尚未看到结果页面，进行了回退或停止重新提交操作，用户提交页面的同步环显然不同于服务器session中的同步环，于是服务器会判定，这是一个重复提交的页面，不予受理。
　　
　　对于同步环的产生、保存、比较，最好生成一个新“同步助手”类SynHelper，完成相应的操作。调用它的Jsp文件只需以JavaBean的形式引用即可。下面描述作为类SynHelper所需的基本方法：
　　
　　private String generateSynId(){
　　　return Long.toString(System.currentTimeMillis());
　　}
　　protected void saveSynId(HttpServletRequest request){
　　　HttpSession session = request.getSession();
　　　session.setAttribute(SYN_ID,generateSynId());
　　}
　　protected boolean compareSynId(HttpServletRequest request){
　　　try{
　　　HttpSession session = request.getSession();
　　　String serverSynId = session.getAttribute(SYN_ID);
　　　String clientSynId = request.getParameter(“CLIENT_SYN_ID”);
　　　Return (serverSynId.equals(clientSynId));
　　}catch(Exception e){
　　　return false;
　　}
　　}
　　
　　对于客户端jsp在收到服务器的同步环后，必须将其保存在hidden中。具体实现如下：
　　
　　　　value=<%=session.getAttribute(“SYN_ID”)%>>