百度助手下载安装,yoast wordpress seo 设置教程,装修全包报价明细表2023,app 门户网站Cookie和Session详解
Session和Cookie详解
会话#xff08;Session#xff09;跟踪是Web程序中常用的技术#xff0c;用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。
Cookie通过在客户端记录信息确定用户身份#xff0c;Session通过在服务器端记录信息…Cookie和Session详解
Session和Cookie详解
会话Session跟踪是Web程序中常用的技术用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。
Cookie通过在客户端记录信息确定用户身份Session通过在服务器端记录信息确定用户身份。
1.1 Cookie机制 在程序中会话跟踪是很重要的事情。理论上一个用户的所有请求操作都应该属于同一个会话而另一个用户的所有请求操作则应该属于另一个会话二者不能混淆。例如用户A在超市购买的任何商品都应该放在A的购物车内不论是用户A什么时间购买的这都是属于同一个会话的不能放入用户B或用户C的购物车内这不属于同一个会话。
而Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕客户端与服务器端的连接就会关闭再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。即用户A购买了一件商品放入购物车内当再次购买商品时服务器已经无法判断该购买行为是属于用户A的会话还是用户B的会话了。要跟踪该会话必须引入一种机制。
Cookie就是这样的一种机制。它可以弥补HTTP协议无状态的不足。在Session出现之前基本上所有的网站都采用Cookie来跟踪会话。
1.1.1 什么是Cookie Cookie意为“甜饼”是由W3C组织提出最早由Netscape社区发展的一种机制。目前Cookie已经成为标准所有的主流浏览器如IE、Netscape、Firefox、Opera等都支持Cookie。
由于HTTP是一种无状态的协议服务器单从网络连接上无从知道客户身份。怎么办呢就给客户端们颁发一个通行证吧每人一个无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。
Cookie实际上是一小段的文本信息。客户端请求服务器如果服务器需要记录该用户状态就使用response向客 户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时浏览器把请求的网址连同该Cookie一同提交给服务 器。服务器检查该Cookie以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
查看某个网站颁发的Cookie很简单。在浏览器地址栏输入javascript:alert (document. cookie)就可以了需要有网才能查看。JavaScript脚本会弹出一个对话框显示本网站颁发的所有Cookie的内容如图1.1所示。 图1.1 Baidu网站颁发的Cookie
图1.1中弹出的对话框中显示的为Baidu网站的Cookie。其中第一行BAIDUID记录的就是笔者的身份helloweenvsfei只是Baidu使用特殊的方法将Cookie信息加密了。 注意Cookie功能需要浏览器的支持。
如果浏览器不支持Cookie如大部分手机中的浏览器或者把Cookie禁用了Cookie功能就会失效。
不同的浏览器采用不同的方式保存Cookie。
IE浏览器会在“C:\Documents and Settings\你的用户名\Cookies”文件夹下以文本文件形式保存一个文本文件保存一个Cookie。 1.1.2 记录用户访问次数 Java中把Cookie封装成了javax.servlet.http.Cookie类。每个Cookie都是该Cookie类的对象。服务器通过操作Cookie类对象对客户端Cookie进行操作。通过request.getCookie()获取客户端提交的所有Cookie以Cookie[]数组形式返回通过response.addCookie(Cookiecookie)向客户端设置Cookie。 Cookie对象使用key-value属性对的形式保存用户状态一个Cookie对象保存一个属性对一个request或者response同时使用多个Cookie。因为Cookie类位于包javax.servlet.http.*下面所以JSP中不需要import该类。
1.1.3 Cookie的不可跨域名性 很多网站都会使用Cookie。例如Google会向客户端颁发CookieBaidu也会向客户端颁发Cookie。那浏览器访问Google会不会也携带上Baidu颁发的Cookie呢或者Google能不能修改Baidu颁发的Cookie呢 答案是否定的。Cookie具有不可跨域名性。根据Cookie规范浏览器访问Google只会携带Google的Cookie而不会携带Baidu的Cookie。Google也只能操作Google的Cookie而不能操作Baidu的Cookie。 Cookie在客户端是由浏览器来管理的。浏览器能够保证Google只会操作Google的Cookie而不会操作 Baidu的Cookie从而保证用户的隐私安全。浏览器判断一个网站是否能操作另一个网站Cookie的依据是域名。Google与Baidu的域名 不一样因此Google不能操作Baidu的Cookie。
需要注意的是虽然网站images.google.com与网站www.google.com同属于Google但是域名不一样二者同样不能互相操作彼此的Cookie。
注意用户登录网站www.google.com之后会发现访问images.google.com时登录信息仍然有效而普通的Cookie是做不到的。这是因为Google做了特殊处理。本章后面也会对Cookie做类似的处理。
1.1.4 Unicode编码保存中文 中文与英文字符不同中文属于Unicode字符在内存中占4个字符而英文属于ASCII字符内存中只占2个字符。Cookie中使用Unicode字符时需要对Unicode字符进行编码否则会乱码。 提示Cookie中保存中文只能编码。一般使用UTF-8编码即可。不推荐使用GBK等中文编码因为浏览器不一定支持而且JavaScript也不支持GBK编码。
1.1.5 BASE64编码保存二进制图片 Cookie不仅可以使用ASCII字符与Unicode字符还可以使用二进制数据。例如在Cookie中使用数字证书提供安全度。使用二进制数据时也需要进行编码。 注意本程序仅用于展示Cookie中可以存储二进制内容并不实用。由于浏览器每次请求服务器都会携带Cookie因此Cookie内容不宜过多否则影响速度。Cookie的内容应该少而精。
1.1.6 设置Cookie的所有属性 除了name与value之外Cookie还具有其他几个常用的属性。每个属性对应一个getter方法与一个setter方法。Cookie类的所有属性如表1.1所示。 表1.1 Cookie常用属性 属 性 名 描 述 String name 该Cookie的名称。Cookie一旦创建名称便不可更改 Object value 该Cookie的值。如果值为Unicode字符需要为字符编码。如果值为二进制数据则需要使用BASE64编码 int maxAge 该Cookie失效的时间单位秒。如果为正数则该Cookie在maxAge秒之后失效。如果为负数该Cookie为临时Cookie关闭浏览器即失效浏览器也不会以任何形式保存该Cookie。如果为0表示删除该Cookie。默认为–1 boolean secure 该Cookie是否仅被使用安全协议传输。安全协议。安全协议有HTTPSSSL等在网络上传输数据之前先将数据加密。默认为false String path 该Cookie的使用路径。如果设置为“/sessionWeb/”则只有contextPath为“/sessionWeb”的程序可以访问该Cookie。如果设置为“/”则本域名下contextPath都可以访问该Cookie。注意最后一个字符必须为“/” String domain 可以访问该Cookie的域名。如果设置为“.google.com”则所有以“google.com”结尾的域名都可以访问该Cookie。注意第一个字符必须为“.” String comment 该Cookie的用处说明。浏览器显示Cookie信息的时候显示该说明 int version 该Cookie使用的版本号。0表示遵循Netscape的Cookie规范1表示遵循W3C的RFC 2109规范 1.1.7 Cookie的有效期
Cookie的maxAge决定着Cookie的有效期单位为秒Second。Cookie中通过getMaxAge()方法与setMaxAge(int maxAge)方法来读写maxAge属性。
如果maxAge属性为正数则表示该Cookie会在maxAge秒之后自动失效。浏览器会将maxAge为正数的 Cookie持久化即写到对应的Cookie文件中。无论客户关闭了浏览器还是电脑只要还在maxAge秒之前登录网站时该Cookie仍然有效。 下面代码中的Cookie信息将永远有效。
Cookie cookie new Cookie(username,helloweenvsfei); // 新建Cookie
cookie.setMaxAge(Integer.MAX_VALUE); // 设置生命周期为MAX_VALUE
response.addCookie(cookie); // 输出到客户端
如果maxAge为负数则表示该Cookie仅在本浏览器窗口以及本窗口打开的子窗口内有效关闭窗口后该 Cookie即失效。maxAge为负数的Cookie为临时性Cookie不会被持久化不会被写到Cookie文件中。Cookie信息保存在浏 览器内存中因此关闭浏览器该Cookie就消失了。Cookie默认的maxAge值为–1。 如果maxAge为0则表示删除该Cookie。Cookie机制没有提供删除Cookie的方法因此通过设置该Cookie即时失效实现删除Cookie的效果。失效的Cookie会被浏览器从Cookie文件或者内存中删除
例如
Cookie cookie new Cookie(username,helloweenvsfei); // 新建Cookie
cookie.setMaxAge(0); // 设置生命周期为0不能为负数
response.addCookie(cookie); // 必须执行这一句 response对象提供的Cookie操作方法只有一个添加操作add(Cookie cookie)。
要想修改Cookie只能使用一个同名的Cookie来覆盖原来的Cookie达到修改的目的。删除时只需要把maxAge修改为0即可。
注意从客户端读取Cookie时包括maxAge在内的其他属性都是不可读的也不会被提交。浏览器提交Cookie时只会提交name与value属性。maxAge属性只被浏览器用来判断Cookie是否过期。
1.1.8 Cookie的修改、删除
Cookie并不提供修改、删除操作。如果要修改某个Cookie只需要新建一个同名的Cookie添加到response中覆盖原来的Cookie。
如果要删除某个Cookie只需要新建一个同名的Cookie并将maxAge设置为0并添加到response中覆盖原来的Cookie。注意是0而不是负数。负数代表其他的意义。读者可以通过上例的程序进行验证设置不同的属性。
注意修改、删除Cookie时新建的Cookie除value、maxAge之外的所有属性例如name、path、domain等都要与原Cookie完全一样。否则浏览器将视为两个不同的Cookie不予覆盖导致修改、删除失败。
1.1.9 Cookie的域名
Cookie是不可跨域名的。域名www.google.com颁发的Cookie不会被提交到域名www.baidu.com去。这是由Cookie的隐私安全机制决定的。隐私安全机制能够禁止网站非法获取其他网站的Cookie。
正常情况下同一个一级域名下的两个二级域名如www.helloweenvsfei.com和 images.helloweenvsfei.com也不能交互使用Cookie因为二者的域名并不严格相同。如果想所有 helloweenvsfei.com名下的二级域名都可以使用该Cookie需要设置Cookie的domain参数例如 Cookie cookie new Cookie(time,20080808); // 新建Cookie
cookie.setDomain(.helloweenvsfei.com); // 设置域名
cookie.setPath(/); // 设置路径
cookie.setMaxAge(Integer.MAX_VALUE); // 设置有效期
response.addCookie(cookie); // 输出到客户端 可以修改本机C:\WINDOWS\system32\drivers\etc下的hosts文件来配置多个临时域名然后使用setCookie.jsp程序来设置跨域名Cookie验证domain属性。
注意domain参数必须以点(.)开始。另外name相同但domain不同的两个Cookie是两个不同的Cookie。如果想要两个域名完全不同的网站共有Cookie可以生成两个Cookiedomain属性分别为两个域名输出到客户端。
*关于Cookie跨域共享
正常的cookie只能在一个应用中共享即一个cookie只能由创建它的应用获得。 1.可在同一应用服务器内共享方法设置cookie.setPath(/); 本机tomcat/webapp下面有两个应用webapp_a和webapp_b 1原来在webapp_a下面设置的cookie在webapp_b下面获取不到path默认是产生cookie的应用的路径。 2若在webapp_a下面设置cookie的时候增加一条cookie.setPath(/);或者cookie.setPath(/webapp_b/); 就可以在webapp_b下面获取到cas设置的cookie了。 3此处的参数是相对于应用服务器存放应用的文件夹的根目录而言的(比如tomcat下面的webapp)因此cookie.setPath(/);之后可以在webapp文件夹下的所有应用共享cookie而cookie.setPath(/webapp_b/); 是指cas应用设置的cookie只能在webapp_b应用下的获得即便是产生这个cookie的webapp_a应用也不可以。 4设置cookie.setPath(/webapp_b/jsp)或者cookie.setPath(/webapp_b/jsp/)的时候只有在webapp_b/jsp下面可以获得cookie在webapp_b下面但是在jsp文件夹外的都不能获得cookie。 5设置cookie.setPath(/webapp_b);是指在webapp_b下面才可以使用cookie这样就不可以在产生cookie的应用webapp_a下面获取cookie了 6有多条cookie.setPath(XXX);语句的时候起作用的以最后一条为准。 2。跨域共享cookie的方法设置cookie.setDomain(.jszx.com); A机所在的域home.langchao.com,A有应用webapp_a B机所在的域jszx.comB有应用webapp_b 1在webapp_a下面设置cookie的时候增加cookie.setDomain(.jszx.com);这样在webapp_b下面就可以取到cookie。 2输入url访问webapp_b的时候必须输入域名才能解析。比如说在A机器输入http://lc-bsp.jszx.com:8080/webapp_b,可以获取webapp_a在客户端设置的cookie而B机器访问本机的应用输入http://localhost:8080/webapp_b则不可以获得cookie。 3设置了cookie.setDomain(.jszx.com);还可以在默认的home.langchao.com下面共享 注通常cookie却不能跨越域传递只有那些创建它的域才能访问同一根域名下的二级域名三级域名可以直接共享。但你可以利用重定向来间接的获取cookies。
1.1.10 Cookie的路径
domain属性决定运行访问Cookie的域名而path属性决定允许访问Cookie的路径ContextPath。例如如果只允许/sessionWeb/下的程序使用Cookie可以这么写
Cookie cookie new Cookie(time,20080808); // 新建Cookie
cookie.setPath(/session/); // 设置路径
response.addCookie(cookie); // 输出到客户端
设置为“/”时允许所有路径使用Cookie。path属性需要使用符号“/”结尾。name相同但domain相同的两个Cookie也是两个不同的Cookie。
注意页面只能获取它属于的Path的Cookie。例如/session/test/a.jsp不能获取到路径为/session/abc/的Cookie。使用时一定要注意。 1.1.11 Cookie的安全属性
HTTP协议不仅是无状态的而且是不安全的。使用HTTP协议的数据不经过任何加密就直接在网络上传播有被截获的可 能。使用HTTP协议传输很机密的内容是一种隐患。如果不希望Cookie在HTTP等非安全协议中传输可以设置Cookie的secure属性为 true。浏览器只会在HTTPS和SSL等安全协议中传输此类Cookie。下面的代码设置secure属性为true Cookie cookie new Cookie(time, 20080808); // 新建Cookie
cookie.setSecure(true); // 设置安全属性
response.addCookie(cookie); // 输出到客户端
提示secure属性并不能对Cookie内容加密因而不能保证绝对的安全性。如果需要高安全性需要在程序中对Cookie内容加密、解密以防泄密。 1.1.12 JavaScript操作Cookie
Cookie是保存在浏览器端的因此浏览器具有操作Cookie的先决条件。浏览器可以使用脚本程序如 JavaScript或者VBScript等操作Cookie。这里以JavaScript为例介绍常用的Cookie操作。例如下面的代码会输出本页面 所有的Cookie。
scriptdocument.write(document.cookie);/script
由于JavaScript能够任意地读写Cookie有些好事者便想使用JavaScript程序去窥探用户在其他网 站的Cookie。不过这是徒劳的W3C组织早就意识到JavaScript对Cookie的读写所带来的安全隐患并加以防备了W3C标准的浏览器会 阻止JavaScript读写任何不属于自己网站的Cookie。换句话说A网站的JavaScript程序读写B网站的Cookie不会有任何结果。
1.1.13 永久登陆案例 实现方式是把账号按照一定的规则加密后连同账号一块保存到Cookie中。下次访问时只需要判断账号的加密规则是否正确即可。本例把账号保存到名为account的Cookie中把账号连同密钥用MD1算法加密后保存到名为ssid的Cookie中。验证时验证Cookie中的账号与密钥加密后是否与Cookie中的ssid相等。 代码示例
1.1.14 cookie与你的主机(域)相关而非你的servlet或JSP页面。因而尽管你的servlet可能只发送了单个cookie你也可能会得到许多不相关的cookie。
1.1.15 如何使用cookie检测初访者
1调用HttpServletRequest.getCookies()获取Cookie数组
2在循环中检索指定名字的cookie是否存在以及对应的值是否正确
3如果是则退出循环并设置区别标识
4根据区别标识判断用户是否为初访者从而进行不同的操作
注不能仅仅因为cookie数组中不存在在特定的数据项就认为用户是个初访者。如果cookie数组为null客户可能是一个初访者也可能是由于用户将cookie删除或禁用造成的结果。但是如果数组非null,也不过是显示客户曾经到过你的网站或域并不能说明他们曾经访问过你的servlet。其它servlet、JSP页面以及非Java Web应用都可以设置cookie依据路径的设置其中的任何cookie都有可能返回给用户的浏览器。正确的做法是判断cookie数组是否为空且是否存在指定的Cookie对象且值正确。某个session中是否存在某个特定的key且其value是否正确 2.Session机制
2.1 Session机制
除了使用CookieWeb应用程序中还经常使用Session来记录客户端状态。Session是服务器端使用的一种记录客户端状态的机制使用上比Cookie简单一些相应的也增加了服务器的存储压力。
2.2.1 什么是Session
Session是另一种记录客户状态的机制不同的是Cookie保存在客户端浏览器中而Session保存在服务器上。客户端浏览器访问服务器的时候服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案客户来访的时候只需要查询客户档案表就可以了。
2.2.2 实现用户登录
Session对应的类为javax.servlet.http.HttpSession类。每个来访者对应一个Session对象所有该客户的状态信息都保存在这个Session对象里。Session对象是在客户端第一次请求服务器的时候创建的。 Session也是一种key-value的属性对通过getAttribute(Stringkey)和setAttribute(String keyObjectvalue)方法读写客户状态信息。Servlet里通过request.getSession()方法获取该客户的 Session
例如
HttpSession session request.getSession(); // 获取Session对象
session.setAttribute(loginTime, new Date()); // 设置Session中的属性
out.println(登录时间为 (Date)session.getAttribute(loginTime)); // 获取Session属性
request还可以使用getSession(boolean create)来获取Session。区别是如果该客户的Session不存在request.getSession()方法会返回null而 getSession(true)会先创建Session再将Session返回。
*何时使用getSession(true) true)即 getSession()getSession()何时使用 getSession(false) 呢
一般情况下若要向Session 中存放数据 则使用 getSession(true) true)即 getSession() 。意义为若当前存在 Session 则使用当前的 Session 若当前不存在 Session 则创建一个新的Session 。因为存放数据是必须要有 Session 的。若要从Session 中获取数据 则一般使用 getSession(false) 。意义为若当前存在 Session则从中获取数据若当前根本就没有 Session 那就更不可能存在 Session 中的数据了。 因为你要查找的数据只可能出现在已经存在的 Session 中而不可能存在于新建的 Session 中。
注一个常见的错误是以为session在有客户端访问时就被创建然而事实是直到某server端程序(如Servlet)调用HttpServletRequest.getSession(true)这样的语句时才会被创建。
Servlet中必须使用request来编程式获取HttpSession对象而JSP中内置了Session隐藏 对象可以直接使用。如果使用声明了%page sessionfalse %则Session隐藏对象不可用。下面的例子使用Session记录客户账号信息。
源代码如下 View Code
注意程序中Session中直接保存了Person类对象与Date类对象使用起来要比Cookie方便。
当多个客户端执行程序时服务器会保存多个客户端的Session。获取Session的时候也不需要声明获取谁的Session。Session机制决定了当前客户只会获取到自己的Session而不会获取到别人的Session。各客户的Session也彼此独立互不可见。
提示Session的使用比Cookie方便但是过多的Session存储在服务器内存中会对服务器造成压力。
2.2.3 Session的生命周期
Session保存在服务器端。为了获得更高的存取速度服务器一般把Session放在内存里。每个用户都会有一个独立的Session。如果Session内容过于复杂当大量客户访问服务器时可能会导致内存溢出。因此Session里的信息应该尽量精简。
Session在用户第一次访问服务器的时候自动创建。需要注意只有访问JSP、Servlet等程序时才会创建Session只访问HTML、IMAGE等静态资源并不会创建Session。如果尚未生成Session也可以使用request.getSession(true)强制生成Session。
Session生成后只要用户继续访问服务器就会更新Session的最后访问时间并维护该Session。用户每访问服务器一次无论是否读写Session服务器都认为该用户的Session“活跃active”了一次。
2.2.4 Session的有效期
由于会有越来越多的用户访问服务器因此Session也会越来越多。为防止内存溢出服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器Session就自动失效了。
Session的超时时间为maxInactiveInterval属性可以通过对应的getMaxInactiveInterval()获取通过setMaxInactiveInterval(longinterval)修改。
Session的超时时间也可以在web.xml中修改。另外通过调用Session的invalidate()方法可以使Session失效。
2.2.5 Session的常用方法
Session中包括各种方法使用起来要比Cookie方便得多。Session的常用方法如表1.2所示。 HttpSession的常用方法 方 法 名 描 述 void setAttribute(String attribute, Object value) 设置Session属性。value参数可以为任何Java Object。通常为Java Bean。value信息不宜过大 String getAttribute(String attribute) 返回Session属性 Enumeration getAttributeNames() 返回Session中存在的属性名 void removeAttribute(String attribute) 移除Session属性 String getId() 返回Session的ID。该ID由服务器自动创建不会重复 long getCreationTime() 返回Session的创建日期。返回类型为long常被转化为Date类型例如Date createTime new Date(session.get CreationTime()) long getLastAccessedTime() 返回Session的最后活跃时间。返回类型为long int getMaxInactiveInterval() 返回Session的超时时间。单位为秒。超过该时间没有访问服务器认为该Session失效 void setMaxInactiveInterval(int second) 设置Session的超时时间。单位为秒 void putValue(String attribute, Object value) 不推荐的方法。已经被setAttribute(String attribute, Object Value)替代 Object getValue(String attribute) 不被推荐的方法。已经被getAttribute(String attr)替代 boolean isNew() 返回该Session是否是新创建的 void invalidate() 使该Session失效
Tomcat中Session的默认超时时间为20分钟。通过setMaxInactiveInterval(int seconds)修改超时时间。可以修改web.xml改变Session的默认超时时间。例如修改为60分钟
session-config session-timeout60/session-timeout !-- 单位分钟 --
/session-config
注意session-timeout参数的单位为分钟而setMaxInactiveInterval(int s)单位为秒。
2.2.6 Session对浏览器的要求 虽然Session保存在服务器对客户端是透明的它的正常运行仍然需要客户端浏览器的支持。这是因为Session 需要使用Cookie作为识别标志。HTTP协议是无状态的Session不能依据HTTP连接来判断是否为同一客户因此服务器向客户端浏览器发送一 个名为JSESSIONID的Cookie它的值为该Session的id也就是HttpSession.getId()的返回值。Session 依据该Cookie来识别是否为同一用户。
该Cookie为服务器自动生成的它的maxAge属性一般为–1表示仅当前浏览器内有效并且各浏览器窗口间不共享关闭浏览器就会失效。
因此同一机器的两个浏览器窗口访问服务器时会生成两个不同的Session。但是由浏览器窗口内的链接、脚本等打开的新窗口也就是说不是双击桌面浏览器图标等打开的窗口除外。这类子窗口会共享父窗口的Cookie因此会共享一个Session。
注意新开的浏览器窗口会生成新的Session但子窗口除外。子窗口会共用父窗口的Session。例如在链接上右击在弹出的快捷菜单中选择“在新窗口中打开”时子窗口便可以访问父窗口的Session。
如果客户端浏览器将Cookie功能禁用或者不支持Cookie怎么办例如绝大多数的手机浏览器都不支持Cookie。Java Web提供了另一种解决方案URL地址重写。
2.2.7 URL地址重写
URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的id信息重写 到URL地址中。服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie也可以使用Session来记录用户状态。 HttpServletResponse类提供了encodeURL(Stringurl)实现URL地址重写例如
td a href%response.encodeURL(index.jsp?c1wdJava) % Homepage/a
/td
该方法会自动判断客户端是否支持Cookie。如果客户端支持Cookie会将URL原封不动地输出来。如果客户端不支持Cookie则会将用户Session的id重写到URL中。重写后的输出可能是这样的
td ahrefindex.jsp;jsessionid0CCD096E7F8D97B0BE608AFDC3E1931E?c 1wdJavaHomepage/a
/td
即在文件名的后面在URL参数的前面添加了字符串“;jsessionidXXX”。其中XXX为Session的 id。分析一下可以知道增添的jsessionid字符串既不会影响请求的文件名也不会影响提交的地址栏参数。用户单击这个链接的时候会把 Session的id通过URL提交到服务器上服务器通过解析URL地址获得Session的id。
如果是页面重定向RedirectionURL地址重写可以这样写
% if(“administrator”.equals(userName)) { response.sendRedirect(response.encodeRedirectURL(“administrator.jsp”)); return; }
%
效果跟response.encodeURL(String url)是一样的如果客户端支持Cookie生成原URL地址如果不支持Cookie传回重写后的带有jsessionid字符串的地址。
对于WAP程序由于大部分的手机浏览器都不支持CookieWAP程序都会采用URL地址重写来跟踪用户会话。比如用友集团的移动商街等。
注意TOMCAT判断客户端浏览器是否支持Cookie的依据是请求中是否含有Cookie。尽管客户端可能会支持Cookie但是由于第一次请求时不会携带任何Cookie因为并无任何Cookie可以携带URL地址重写后的地址中仍然会带有jsessionid。当第二次访问时服务器已经在浏览器中写入Cookie了因此URL地址重写后的地址中就不会带有jsessionid了。
2.2.8 Session中禁止使用Cookie
既然WAP上大部分的客户浏览器都不支持Cookie索性禁止Session使用Cookie统一使用URL地址重写会更好一些。Java Web规范支持通过配置的方式禁用Cookie。下面举例说一下怎样通过配置禁止使用Cookie。
打开项目sessionWeb的WebRoot目录下的META-INF文件夹跟WEB-INF文件夹同级如果没有则创建打开context.xml如果没有则创建编辑内容如下
代码1.11 /META-INF/context.xml
?xml version1.0 encodingUTF-8?
Context path/sessionWebcookiesfalse
/Context
或者修改Tomcat全局的conf/context.xml修改内容如下
代码1.12 context.xml
!-- The contents of this file will be loaded for eachweb application --
Context cookiesfalse !-- ... 中间代码略 --
/Context
部署后TOMCAT便不会自动生成名JSESSIONID的CookieSession也不会以Cookie为识别标志而仅仅以重写后的URL地址为识别标志了。
注意该配置只是禁止Session使用Cookie作为识别标志并不能阻止其他的Cookie读写。也就是说服务器不会自动维护名为JSESSIONID的Cookie了但是程序中仍然可以读写其他的Cookie。
*2.2.9 Session的工作原理面试考点
1 写入 Session 列表 服务器对 当前应用中的 Session 是 以 Map 的形式进行管理的 这个 Map 称为 Session 列表 。 该 Map 的 key 为一个 32 位长度的随机串这个随机 串称为 JSessionID value 则为 Session对象 的引用 。 当用户第一次提交请求时服务端 Servlet 中执行 到 request.getSession() 方法后会自动生成一个 Map.Entry 对象 key 为一个根据某种算法新生成的 JSessionID value 则为新创建的 HttpSession 对象。 2 服务器生成并发送 Cookie 在将Session 信息写 入 Session 列表后 系统还会自动 将 JSESSIONID 作为 name 这个 32 位长度的 随机串作为 value 以 Cookie 的形式 存放到响应报头中并随着响应将 该Cookie 发送 到客户端。 3 客户端接收并发送 Cookie 客户端接收到这个 Cookie 后会将其存放到浏览器的缓存中。 即只要客户端浏览器不关闭浏览器缓存中的 Cookie 就不会消失。当用户提交第二次请求时会将 缓存中的这个 Cookie 伴随着请求的头部信息一块发送到服务端。 4 从 Session 列表中查找 服务端从请求中读取到客户端发送来的Cookie 并根据 Cookie 的 JSSESSIONID 的 值从Map 中查找相应 key 所对应的 value 即 Session 对象。然后对该 Session 对象的域属性进行读写操作。 Session和Cookie的区别
1、cookie数据存放在客户的浏览器上session数据放在服务器上。
2、cookie不是很安全别人可以分析存放在本地的COOKIE并进行COOKIE欺骗考虑到安全应当使用session。
Cookie欺骗例子https://www.cnblogs.com/mq0036/p/9110710.html
3、session会在一定时间内保存在服务器上。当访问增多会比较占用你服务器的性能 考虑到减轻服务器性能方面应当使用COOKIE。
4、单个cookie保存的数据不能超过4K很多浏览器都限制一个站点最多保存20个cookie。
5、所以个人建议将登陆信息等重要信息存放为SESSION其他信息如果需要保留可以放在COOKIE中 保存session Id的几种方式
1保存session id的方式可以采用cookie这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。
2由于cookie可以被人为的禁止必须有其它的机制以便在cookie被禁止时仍然能够把session id传递回服务器经常采用的一种技术叫做URL重写就是把session id附加在URL路径的后面附加的方式也有两种一种是作为URL路径的附加信息另一种是作为查询字符串附加在URL后面。网络在整个交互过程中始终保持状态就必须在每个客户端可能请求的路径后面都包含这个session id。
3另一种技术叫做表单隐藏字段。就是服务器会自动修改表单添加一个隐藏字段以便在表单提交时能够把session id传递回服务器。 session何时被删除?
session在下列情况下被删除
1程序调用HttpSession.invalidate( )
2距离上一次收到客户端发送的session id时间间隔超过了session的最大有效时间
3服务器进程被停止
再次注意关闭浏览器只会使存储在客户端浏览器内存中的session cookie失效不会使服务器端的session对象失效。 URL重写有什么缺点? 对所有的URL使用URL重写包括超链接form的action和重定向的URL。每个引用你的站点的URL以及那些返回给用户的URL(即使通过间接手段比如服务器重定向中的Location字段)都要添加额外的信息. 这意味着在你的站点上不能有任何静态的HTML页面(至少静态页面中不能有任何链接到站点动态页面的链接)。因此每个页面都必须使用servlet或JSP动态生成。即使所有的页面都动态生成如果用户离开了会话并通过书签或链接再次回来会话的信息都会丢失因为存储下来的链接含有错误的标识信息该URL后面的SESSION ID已经过期了。 使用隐藏的表单域有什么缺点 仅当每个页面都是有表单提交而动态生成时才能使用这种方法。单击常规的A HREF..超文本链接并不产生表单提交因此隐藏的表单域不能支持通常的会话跟踪只能用于一系列特定的操作中比如在线商店的结账过程 会话属性的类型有什么限制吗
通常会话属性的类型只要是Object就可以了。除了null或基本类型如int,double,boolean。如果要使用基本类型的值作为属性必须将其转换为相应的封装类对象 如何废弃会话数据 1.只移除自己编写的servlet创建的数据调用removeAttribute(“key”)将指定键关联的值废弃 2删除整个会话(在当前Web应用中)调用invalidate将整个会话废弃掉。这样做会丢失该用户的所有会话数据而非仅仅由我们servlet或JSP页面创建的会话数据 3将用户从系统中注销并删除所有属于他(或她)的会话调用logOut将客户从Web服务器中注销同时废弃所有与该用户相关联的会话(每个Web应用至多一个)。这个操作有可能影响到服务器上多个不同的Web应用。 如何使用会话显示每个客户的访问次数 由于客户的访问次数是一个整型的变量但session的属性类型中不能使用intdoubleboolean等基本类型的变量所以我们要用到这些基本类型的封装类型对象作为session对象中属性的值但像Integer是一种不可修改(Immutable)的数据结构构建后就不能更改。这意味着每个请求都必须创建新的Integer对象之后使用setAttribute来代替之前存在的老的属性的值。 sessionid如何产生由谁产生保存在哪里
sessionid是一个会话的key浏览器第一次访问服务器会在服务器端生成一个session有一个sessionid和它对应。tomcat生成的sessionid叫做jsessionid。
session在访问tomcat服务器HttpServletRequest的getSession(true)的时候创建tomcat的ManagerBase类提供创建sessionid的方法随机数时间jvmid
存储在服务器的内存中tomcat的StandardManager类将session存储在内存中也可以持久化到file数据库memcacheredis等。客户端只保存sessionid到cookie中而不会保存sessionsession销毁只能通过invalidate或超时关掉浏览器并不会关闭session。
session存放在哪里服务器端的内存中。不过session可以通过特殊的方式做持久化管理memcacheredis。
session的id是从哪里来的sessionID是如何使用的当客户端第一次请求session对象时候服务器会为客户端创建一个session并将通过特殊算法算出一个session的ID用来标识该session对象
tomcat中session的创建 ManagerBase是所有session管理工具类的基类它是一个抽象类所有具体实现session管理功能的类都要继承这个类该类有一个受保护的方法该方法就是创建sessionId值的方法 tomcat的session的id值生成的机制是一个随机数加时间加上jvm的id值jvm的id值会根据服务器的硬件信息计算得来因此不同jvm的id值都是唯一的 StandardManager类是tomcat容器里默认的session管理实现类 它会将session的信息存储到web容器所在服务器的内存里。 PersistentManagerBase也是继承ManagerBase类它是所有持久化存储session信息的基类PersistentManager继承了PersistentManagerBase但是这个类只是多了一个静态变量和一个getName方法目前看来意义不大对于持久化存储sessiontomcat还提供了StoreBase的抽象类它是所有持久化存储session的基类另外tomcat还给出了文件存储FileStore和数据存储JDBCStore两个实现。
