JavaWeb之会话与状态管理

 

提出问题

 

HTTP协议是一种无状态的协议，WEB服务器本身不能识别出哪些请求是同一个浏览器发出的 ，浏览器的每一次请求都是完全孤立的。

即使 HTTP1.1 支持持续连接，但当用户有一段时间没有提交请求，连接也会关闭。

怎么才能实现网上商店中的购物车呢：某个用户从网站的登录页面登入后，再进入购物页面购物时，负责处理购物请求的服务器程序必须知道处理上一次请求的程序所得到的用户信息。 

作为 web 服务器，必须能够采用一种机制来唯一地标识一个用户，同时记录该用户的状态。

 

会话和会话状态

 

WEB应用中的会话是指一个客户端浏览器与WEB服务器之间连续发生的一系列请求和响应过程。

WEB应用的会话状态是指WEB服务器与浏览器在会话过程中产生的状态信息，借助会话状态，WEB服务器能够把属于同一会话中的一系列的请求和响应过程关联起来。 

 

如何实现有状态的会话

 

WEB服务器端程序要能从大量的请求消息中区分出哪些请求消息属于同一个会话，即能识别出来自同一个浏览器的访问请求，这需要浏览器对其发出的每个请求消息都进行标识：属于同一个会话中的请求消息都附带同样的标识号，而属于不同会话的请求消息总是附带不同的标识号，这个标识号就称之为会话ID（SessionID）。 

在 Servlet 规范中，常用Cookie和Session两种机制完成会话跟踪。 

  

 

Cookie机制 

 

Cookie机制采用的是在客户端保持 HTTP 状态信息的方案 

Cookie是在浏览器访问WEB服务器的某个资源时，由WEB服务器在HTTP响应消息头中附带传送给浏览器的一个小文本文件。 

一旦WEB浏览器保存了某个Cookie，那么它在以后每次访问该WEB服务器时，都会在HTTP请求头中将这个Cookie回传给WEB服务器。

底层的实现原理： WEB服务器通过在HTTP响应消息中增加Set-Cookie响应头字段将Cookie信息发送给浏览器，浏览器则通过在HTTP请求消息中增加Cookie请求头字段将Cookie回传给WEB服务器。

一个Cookie只能标识一种信息，它至少含有一个标识该信息的名称（NAME）和设置值（VALUE）。 

一个WEB站点可以给一个WEB浏览器发送多个Cookie，一个WEB浏览器也可以存储多个WEB站点提供的Cookie。

浏览器一般只允许存放300个Cookie，每个站点最多存放20个Cookie，每个Cookie的大小限制为4KB。

 

Cookie的传送过程示意图 

 

  

 

在Servlet程序中使用Cookie 

 

Servlet API中提供了一个javax.servlet.http.Cookie类来封装Cookie信息，它包含有生成Cookie信息和提取Cookie信息的各个属性的方法。 

Cookie类的方法： 

构造方法： public Cookie(String name,String value)

getName方法 

setValue与getValue方法 

setMaxAge与getMaxAge方法 

setPath与getPath方法 

HttpServletResponse接口中定义了一个addCookie方法，它用于在发送给浏览器的HTTP响应消息中增加一个Set-Cookie响应头字段。

HttpServletRequest接口中定义了一个getCookies方法，它用于从HTTP请求消息的Cookie请求头字段中读取所有的Cookie项。

 

 

Cookie的发送 

 

1.创建Cookie对象

2.设置最大时效

3.将Cookie放入到HTTP响应报头

如果创建了一个cookie，并将他发送到浏览器，默认情况下它是一个会话级别的cookie; 存储在浏览器的内存中，用户退出浏览器之后被删除。若希望浏览器将该cookie存储在磁盘上，则需要使用maxAge，并给出一个以秒为单位的时间。将最大时效设为0则是命令浏览器删除该cookie。

发送cookie需要使用HttpServletResponse的addCookie方法，将cookie插入到一个 Set-Cookie　HTTP响应报头中。由于这个方法并不修改任何之前指定的Set-Cookie报头，而是创建新的报头，因此将这个方法称为是addCookie，而非setCookie。

 

 

会话cookie和持久cookie的区别 

 

如果不设置过期时间，则表示这个cookie生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览器会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。

如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie依然有效直到超过设定的过期时间。

存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存的cookie，不同的浏览器有不同的处理方式。

 

 

Cookie的读取 

 

1.调用request.getCookies

   要获取浏览器发送来的cookie，需要调用HttpServletRequest的getCookies方法，这个调用返回Cookie对象的数组，对应由HTTP请求中Cookie报头输入的值。

2.对数组进行循环，调用每个cookie的getName方法，直到找到感兴趣的cookie为止

 

设置Cookie的作用路径

 

setPath()

 

Cookie使用案例

 

案例一：

 

自动登录：

不需要填写用户名和密码等信息，可以自动登录到系统

 

案例二： 

显示最近浏览的 5 本书的 title

 

案例三： 

跟踪用户上次访问站点的时间

 

功能：

帮助网站实现提示客户端计算机上次访问网站的时间 

实现原理：

将每一个会话作为一次访问过程，将每次会话的开始时间作为每次访问网站的时间，然后将这个时间以Cookie的形式存储到客户端的计算机中，客户端进行下次访问时通过该Cookie回传上次访问站点的时间值。 

为了让Cookie信息在客户端浏览器或计算机关闭后仍然保持存在，Cookie的保存时间被设置为了一年。 

 

Session机制

 

session机制采用的是在服务器端保持 HTTP 状态信息的方案 。

服务器使用一种类似于散列表的结构(也可能就是使用散列表)来保存信息。

当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否包含了一个session标识(即sessionId),如果已经包含一个sessionId则说明以前已经为此客户创建过session，服务器就按照session id把这个session检索出来使用(如果检索不到，可能会新建一个，这种情况可能出现在服务端已经删除了该用户对应的session对象，但用户人为地在请求的URL后面附加上一个JSESSION的参数)。如果客户请求不包含sessionId，则为此客户创建一个session并且生成一个与此session相关联的sessionId，这个session id将在本次响应中返回给客户端保存。

 

session在不同环境下的不同含义 

 

session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话是从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个session。

session在Web开发环境下的语义又有了新的扩展，它的含义是指一类用来在客户端与服务器端之间保持状态的解决方案。有时候Session也用来指这种解决方案的存储结构。

 

保存session id的几种方式 

 

保存session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。

由于cookie可以被人为的禁用，必须有其它的机制以便在cookie被禁用时仍然能够把session id传递回服务器，经常采用的一种技术叫做URL重写，就是把session id附加在URL路径的后面，附加的方式也有两种，一种是作为URL路径的附加信息，另一种是作为查询字符串附加在URL后面。网络在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。

 

Session cookie

 

session通过SessionID来区分不同的客户, session是以cookie或URL重写为基础的，默认使用cookie来实现，系统会创造一个名为JSESSIONID的输出cookie，这称之为session cookie,以区别persistent cookies(也就是我们通常所说的cookie),session cookie是存储于浏览器内存中的，并不是写到硬盘上的，通常看不到JSESSIONID，但是当把浏览器的cookie禁止后，web服务器会采用URL重写的方式传递Sessionid，这时地址栏看到session cookie针对某一次会话而言，会话结束session cookie也就随着消失了，而persistent cookie只是存在于客户端硬盘上的一段文本。 

关闭浏览器，只会是浏览器端内存里的session cookie消失，但不会使保存在服务器端的session对象消失，同样也不会使已经保存到硬盘上的持久化cookie消失。

 

Session的创建与删除 

 

一个常见的错误是以为session在有客户端访问时就被创建，然而事实是直到某server端程序(如Servlet)调用HttpServletRequest.getSession(true) 或者 HttpServletRequest.getSession()这样的语句时才会被创建。

session在下列情况下被删除：

A．程序调用HttpSession.invalidate()

B．距离上一次收到客户端发送的session id时间间隔超过了session的最大有效时间

C．服务器进程被停止

注意：关闭浏览器只会使存储在客户端浏览器内存中的session cookie失效，不会使服务器端的session对象失效。

 

两个浏览器窗口访问应用程序会使用同一个session 

 

通常session cookie是不能跨窗口使用的(IE 8 版本以前)，当你新开了一个浏览器窗口进入相同页面时，系统会赋予你一个新的session id，这样信息共享的目的就达不到了。

此时可以先把session id保存在persistent cookie中(通过设置cookie的最大有效时间)，然后在新窗口中读出来，就可以得到上一个窗口的session id了，这样通过session cookie和persistent cookie的结合就可以实现了跨窗口的会话跟踪。

  

Session的超时管理 

 

WEB服务器无法判断当前的客户端浏览器是否还会继续访问，也无法检测客户端浏览器是否关闭，所以，即使客户已经离开或关闭了浏览器，WEB服务器还要保留与之对应的HttpSession对象。 

随着时间的推移而不断增加新的访问客户端，WEB服务器内存中将会因此积累起大量的不再被使用的HttpSession对象，并将最终导致服务器内存耗尽。 

WEB服务器采用“超时限制”的办法来判断客户端是否还在继续访问，如果某个客户端在一定的时间之内没有发出后续请求，WEB服务器则认为客户端已经停止了活动，结束与该客户端的会话并将与之对应的HttpSession对象变成垃圾。

如果客户端浏览器超时后再次发出访问请求，WEB服务器则认为这是一个新的会话的开始，将为之创建新的HttpSession对象和分配新的会话标识号。 

会话的超时间隔可以在web.xml文件中设置，其默认值由Servlet容器定义。 

<session-config>

<session-timeout>30</session-timeout>

</session-config>

  

HttpSession接口中的方法 

 

getId方法

getCreationTime方法

getLastAccessedTime方法

setMaxInactiveInterval方法

getMaxInactiveInterval方法

isNew方法

如果客户端请求消息中返回了一个与Servlet程序当前获得的HttpSession对象的会话标识号相同的会话标识号，则认为这个HttpSession对象不是新建的。

invalidate方法

getServletContext方法

setAttribute方法

getAttribute方法

removeAttribute方法

getAttributeNames方法

  

HttpServletRequest接口中的Session方法 

 

getSession方法 

public HttpSession getSession(boolean create)

public HttpSession getSession()

isRequestedSessionIdValid方法 

isRequestedSessionIdFromCookie方法 

isRequestedSessionIdFromURL方法 

 

 

案例一

 

购书

 

  

 

利用URL重写实现Session跟踪 

 

Servlet规范中引入了一种补充的会话管理机制，它允许不支持Cookie的浏览器也可以与WEB服务器保持连续的会话。这种补充机制要求在响应消息的实体内容中必须包含下一次请求的超链接，并将会话标识号作为超链接的URL地址的一个特殊参数。 将会话标识号以参数形式附加在超链接的URL地址后面的技术称为URL重写。如果在浏览器不支持Cookie或者关闭了Cookie功能的情况下，WEB服务器还要能够与浏览器实现有状态的会话，就必须对所有可能被客户端访问的请求路径（包括超链接、form表单的action属性设置和重定向的URL）进行URL重写。 

HttpServletResponse接口中定义了两个用于完成URL重写方法：

encodeURL方法 

encodeRedirectURL方法

  

application域范围的属性 

 

 

 

Session域范围的属性 

 

 

 

HttpSession 的生命周期：

 

1). 什么时候创建 HttpSession 对象

①. 对于 JSP: 是否浏览器访问服务端的任何一个 JSP, 服务器都会立即创建一个 HttpSession 对象呢？

不一定。

> 若当前的 JSP 是客户端访问的当前 WEB 应用的第一个资源，且 JSP 的 page 指定的 session 属性值为 false, 

则服务器就不会为 JSP 创建一个 HttpSession 对象;

 

> 若当前 JSP 不是客户端访问的当前 WEB 应用的第一个资源，且其他页面已经创建一个 HttpSession 对象，

则服务器也不会为当前 JSP 页面创建一个 HttpSession 对象，而回会把和当前会话关联的那个 HttpSession 对象返回给当前的 JSP 页面.

 

②. 对于 Serlvet: 若 Serlvet 是客户端访问的第一个 WEB 应用的资源,

则只有调用了 request.getSession() 或 request.getSession(true) 才会创建 HttpSession 对象

 

2). page 指令的 session=“false“  到底表示什么意思？

 

> 当前 JSP 页面禁用 session 隐含变量！但可以使用其他的显式的 HttpSession 对象

 

3). 在 Serlvet 中如何获取 HttpSession 对象？

 

> request.getSession(boolean create): 

create 为 false, 若没有和当前 JSP 页面关联的 HttpSession 对象, 则返回 null; 若有, 则返回 true

create 为 true, 一定返回一个 HttpSession 对象. 若没有和当前 JSP 页面关联的 HttpSession 对象, 则服务器创建一个新的

HttpSession 对象返回, 若有, 直接返回关联的. 

 

> request.getSession(): 等同于 request.getSession(true)

 

4). 什么时候销毁 HttpSession 对象:

 

①. 直接调用 HttpSession 的 invalidate() 方法: 该方法使 HttpSession 失效

 

②. 服务器卸载了当前 WEB 应用. 

 

③. 超出 HttpSession 的过期时间.

 

> 设置 HttpSession 的过期时间: session.setMaxInactiveInterval(5); 单位为秒

 

> 在 web.xml 文件中设置 HttpSession 的过期时间: 单位为 分钟. 

 

<session-config>

        <session-timeout>30</session-timeout>

    </session-config>

    

④. 并不是关闭了浏览器就销毁了 HttpSession. 

  

 

Session的典型案例

 

使用Session实现购物车 

利用Session防止表单重复提交 

利用Session实现一次性验证码 

 

 

 

练习：简易session版购物车 

 

创建一个简单的购物车模型，由三个 jsp 和两个 Servlet 组成：

 

 

 

避免表单的重复提交

 

调用 RequestDispatcher.forward() 方法，浏览器所保留的URL 是先前的表单提交的 URL，此时点击”刷新”, 浏览器将再次提交用户先前输入的数据，引起重复提交

如果采用 HttpServletResponse.sendRedirct() 方法将客户端重定向到成功页面，将不会出现重复一条问题

 

 

JS 客户端避免表单重复提交

 

 

 

不足：但用户单击”刷新”，或单击”后退”再次提交表单，将导致表单重复提交 

 

利用Session防止表单重复提交

 

包含有FORM表单的页面必须通过一个服务器程序动态产生，服务器程序为每次产生的页面中的FORM表单都分配一个唯一的随机标识号，并在FORM表单的一个隐藏字段中设置这个标识号，同时在当前用户的Session域中保存这个标识号。 

当用户提交FORM表单时，负责接收这一请求的服务器程序比较FORM表单隐藏字段中的标识号与存储在当前用户的Session域中的标识号是否相同，如果相同则处理表单数据，处理完后清除当前用户的Session域中存储的标识号。在下列情况下，服务器程序将忽略提交的表单请求：

当前用户的Session中不存在表单标识号

用户提交的表单数据中没有标识号字段

存储在当前用户的Session域中的表单标识号与表单数据中的标识号不同

浏览器只有重新向WEB服务器请求包含FORM表单的页面时，服务器程序才又产生另外一个随机标识号，并将这个标识号保存在Session域中和作为新返回的FORM表单中的隐藏字段值。 

 

 

TokenProcessor.java：用于管理表单标识号的工具类，它主要用于产生、比较和清除存储在当前用户Session中的表单标识号。为了保证表单标识号的唯一性，每次将当前SessionID和系统时间的组合值按MD5算法计算的结果作为表单标识号，并且将TokenProcessor类设计为单件类

 

 

问题：

同一个用户打开同一个浏览器进程的多个窗口来并发访问同一个WEB站点的多个FORM表单页面时，将会出现表单无法正常提交的情况。 

解决方案：

将FORM表单的标识号作为表单隐藏字段的名称，如下所示：

<input type='hidden' name='4b15c6b2f573831b4b5107d849fcafb8' value=''>

将所有的表单标识号存储进一个Vector集合对象中，并将Vector集合对象存储进Session域中。当表单提交时，先从Session域中取出Vector集合对象，然后再从Vector集合对象中逐一取出每个表单标识号作为参数调用HttpServletRequest.getParameter方法，如果其中有一次调用的返回值不为null，则接受并处理该表单数据，处理完后将该表单标识号从Vector集合对象中删除。

 

3. 表单的重复提交

 

1). 重复提交的情况: 

①. 在表单提交到一个 Servlet, 而 Servlet 又通过请求转发的方式响应一个 JSP(HTML) 页面, 

此时地址栏还保留着 Serlvet 的那个路径, 在响应页面点击 "刷新" 

②. 在响应页面没有到达时重复点击 "提交按钮". 

③. 点击 "返回", 再点击 "提交"

 

2). 不是重复提交的情况: 点击 "返回", "刷新" 原表单页面, 再 "提交"。

 

3). 如何避免表单的重复提交: 在表单中做一个标记, 提交到 Servlet 时, 检查标记是否存在且是否和预定义的标记一致, 若一致, 则受理请求,

并销毁标记, 若不一致或没有标记, 则直接响应提示信息: "重复提交" 

 

①. 仅提供一个隐藏域: <input type="hidden" name="token" value="atguigu"/>. 行不通: 没有方法清除固定的请求参数. 

②. 把标记放在 request 中. 行不通, 因为表单页面刷新后, request 已经被销毁, 再提交表单是一个新的 request.

③. 把标记放在 session 中. 可以！

 

> 在原表单页面, 生成一个随机值 token

> 在原表单页面, 把 token 值放入 session 属性中

> 在原表单页面, 把 token 值放入到 隐藏域 中.

 

> 在目标的 Servlet 中: 获取 session 和 隐藏域 中的 token 值

> 比较两个值是否一致: 若一致, 受理请求, 且把 session 域中的 token 属性清除

> 若不一致, 则直接响应提示页面: "重复提交"

 

 

利用Session实现一次性验证码 

 

一次性验证码的主要目的就是为了限制人们利用工具软件来暴力猜测密码，其原理与利用Session防止表单重复提交的原理基本一样，只是将表单标识号变成了验证码的形式，并且要求用户将提示的验证码手工填写进一个表单字段中，而不是通过表单的隐藏字段自动回传给服务器。 

服务器程序接收到表单数据后，首先判断用户是否填写了正确的验证码，只有该验证码与服务器端保存的验证码匹配时，服务器程序才开始正常的表单处理流程。 

密码猜测工具要逐一尝试每个密码的前题条件是先输入正确的验证码，而验证码是一次性有效的，这样基本上就阻断了密码猜测工具的自动地处理过程。 

 

1). 基本原理: 和表单重复提交一致:

 

> 在原表单页面, 生成一个验证码的图片, 生成图片的同时, 需要把该图片中的字符串放入到 session 中. 

> 在原表单页面, 定义一个文本域, 用于输入验证码. 

 

> 在目标的 Servlet 中: 获取 session 和 表单域 中的 验证码的 值

> 比较两个值是否一致: 若一致, 受理请求, 且把 session 域中的 验证码 属性清除

 

> 若不一致, 则直接通过重定向的方式返回原表单页面, 并提示用户 "验证码错误"

 

JavaWEB中的相对路径和绝对路径

 

1. 绝对路径问题：

1）开发时建议写“绝对路径”：使用相对路径可能会有问题, 但使用绝对路径肯定没有问题. 

 

在由Servlet转发到jsp页面时，此时浏览器地址栏上显示的是Servlet的路径，而若jsp页面的超链接还是相对于jsp页面的地址，则可能出现路径混乱的问题。

 

/a.jsp

  -path

        /b.jsp

        /c.jsp

 

a.jsp -> /servlet --转发--> b.jsp（有一超链接：和b.jsp在同一路径下的c.jsp）--> 无法找到页面

 

2） 绝对路径可以解决以上问题

 

2.1 在JavaWeb中，什么是绝对路径？

 

      相对于当前WEB应用的跟路径的路径。即任何路径必须带上contextPath

 

2.2 在JavaWeb中，如何编写绝对路径？

 

在超链接中添加应用跟路径：request.getContextPath()

 

2. 使用绝对路径：使用相对路径可能会有问题, 但使用绝对路径肯定没有问题. 

 

1). 绝对路径： 相对于当前 WEB 应用的路径. 在当前 WEB 应用的所有的路径前都添加 contextPath 即可. 

 

2). / 什么时候代表站点的根目录, 什么时候代表当前 WEB 应用的根目录

 

若 / 需要服务器进行内部解析, 则代表的就是 WEB 应用的根目录. 若是交给浏览器了, 则 / 代表的就是站点的根目录

若 / 代表的是 WEB 应用的根目录, 就不需要加上 contextPath 了. 

 

3) JavaWEB 中 / 到底代表什么？

 

3.1 当前WEB应用的跟路径：http://localhost:8090/contextPath/   若斜杠交由Servlet容器来处理

 

      >请求转发时：request.getRequestDispathcher("/path/b.jsp").forward(request,response);

      >web.xml 文件映射servelt访问路径

         <servlet-mapping>

             <servlet-name>TestServlet</servlet-name>

             <url-pattern>testServlet</url-pattern>

         </servlet-mapping>

       >各种定制标签中的斜杠

 

3.2 WEB站点的跟路径 http://localhost:8090/    若斜杠交由浏览器来处理

     

       >超链接： <a href="/TestServlet"></a>

       >表单中的action: <form action="/login.jsp"></form>

       >请求重定向：response.sendRedirect(“/a.jsp”);