cookie和session专题

一、 cookie 机制和 session 机制的区别
*****************************************************************
具体来说 cookie 机制采用的是在客户端保持状态的方案，而 session 机制采用的是在服务器端保持状态的方案。
同时我们也看到，由于才服务器端保持状态的方案在客户端也需要保存一个标识，所以 session
机制可能需要借助于 cookie 机制来达到保存标识的目的，但实际上还有其他选择
*****************************************************************

二、会话 cookie 和持久 cookie 的区别
****************************************************************
如果不设置过期时间，则表示这个 cookie 生命周期为浏览器会话期间，只要关闭浏览器窗口， cookie 就消失了。这种生命期为浏览会话期的 cookie 被称为会话 cookie 。会话 cookie 一般不保存在硬盘上而是保存在内存里。
　　如果设置了过期时间，浏览器就会把 cookie 保存到硬盘上，关闭后再次打开浏览器，这些 cookie 依然有效直到超过设定的过期时间。
　　存储在硬盘上的 cookie 可以在不同的浏览器进程间共享，比如两个 IE 窗口。而对于保存在内存的 cookie ，不同的浏览器有不同的处理方式。
****************************************************************

三、如何利用实现自动登录
****************************************************************
　　当用户在某个网站注册后，就会收到一个惟一用户 ID 的 cookie 。客户后来重新连接时，这个
用户 ID 会自动返回，服务器对它进行检查，确定它是否为注册用户且选择了自动登录，从而使用户务需给出明确的用户名和密码，就可以访问服务器上的资源。
********************************************************************

四、如何根据用户的爱好定制站点
******************************************************************
　　网站可以使用 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 的读取
**************************************************************
1. 调用 request.getCookie
要获取有浏览器发送来的 cookie ，需要调用 HttpServletRequest 的 getCookies 方法，这个调用返回 Cookie 对象的数组，对应由 HTTP 请求中 Cookie 报头输入的值。
2. 对数组进行循环，调用每个 cookie 的 getName 方法，直到找到感兴趣的 cookie 为止
　 cookie 与你的主机 ( 域 ) 相关，而非你的 servlet 或 JSP 页面。因而，尽管你的 servlet 可能只发送了单个 cookie ，你也可能会得到许多不相关的 cookie 。
例如：
　　 String cookieName = “userID”;
    Cookie cookies[] = request.getCookies();
    if (cookies!=null){
        for(int i=0;i<cookies.length;i++){
    Cookie cookie = cookies[i];
    if (cookieName.equals(cookie .getName())){
        doSomethingWith(cookie .getValue());
}
}
}
******************************************************************

七、如何使用 cookie 检测初访者
**************************************************************
A. 调用 HttpServletRequest.getCookies() 获取 Cookie 数组
B. 在循环中检索指定名字的 cookie 是否存在以及对应的值是否正确
C. 如果是则退出循环并设置区别标识
D. 根据区别标识判断用户是否为初访者从而进行不同的操作
****************************************************************

八、使用 cookie 检测初访者的常见错误
****************************************************************
不能仅仅因为 cookie 数组中不存在在特定的数据项就认为用户是个初访者。如果 cookie 数组为 null ，客户可能是一个初访者，也可能是由于用户将 cookie 删除或禁用造成的结果。
但是，如果数组非 null, 也不过是显示客户曾经到过你的网站或域，并不能说明他们曾经访问过你的 servlet 。其它 servlet 、 JSP 页面以及非 Java Web 应用都可以设置 cookie ，依据路径的设置，其中的任何 cookie 都有可能返回给用户的浏览器。
正确的做法是判断 cookie 数组是否为空且是否存在指定的 Cookie 对象且值正确。
*******************************************************************

九、使用 cookie 属性的注意问题
*******************************************************************
　　属性是从服务器发送到浏览器的报头的一部分；但它们不属于由浏览器返回给服务器的报头。　
　　因此除了名称和值之外， cookie 属性只适用于从服务器输出到客户端的 cookie ；服务器端来自于浏览器的 cookie 并没有设置这些属性。　
　　因而不要期望通过 request.getCookies 得到的 cookie 中可以使用这个属性。这意味着，你不能仅仅通过设置 cookie 的最大时效，发出它，在随后的输入数组中查找适当的 cookie , 读取它的值，修改它并将它存回 Cookie ，从而实现不断改变的 cookie 值。
*******************************************************************

十、如何使用 cookie 记录各个用户的访问计数
********************************************************************
1. 获取 cookie 数组中专门用于统计用户访问次数的 cookie 的值
2. 将值转换成 int 型
3. 将值加 1 并用原来的名称重新创建一个 Cookie 对象
4. 重新设置最大时效
5. 将新的 cookie 输出
****************************************************************

十一、 session 在不同环境下的不同含义
*****************************************************************
session ，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作 / 消息，比如打电话是从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个 session 。
然而当 session 一词与网络协议相关联时，它又往往隐含了 “ 面向连接 ” 和 / 或 “ 保持状态 ” 这样两个含义。
　　 session 在 Web 开发环境下的语义又有了新的扩展，它的含义是指一类用来在客户端与服务器端之间保持状态的解决方案。有时候 Session 也用来指这种解决方案的存储结构。
********************************************************************

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

十三、保存 session id 的几种方式
******************************************************************
A ．保存 session id 的方式可以采用 cookie ，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。
B ．由于 cookie 可以被人为的禁止，必须有其它的机制以便在 cookie 被禁止时仍然能够把 session id 传递回服务器，经常采用的一种技术叫做 URL 重写，就是把 session id 附加在 URL 路径的后面，附加的方式也有两种，一种是作为 URL 路径的附加信息，另一种是作为查询字符串附加在 URL 后面。网络在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个 session id 。
C ．另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把 session id 传递回服务器。
******************************************************************

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

十五、 session 何时被删除
*******************************************************************
session 在下列情况下被删除：
A ．程序调用 HttpSession.invalidate()
B ．距离上一次收到客户端发送的 session id 时间间隔超过了 session 的最大有效时间
C ．服务器进程被停止

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

十六、 URL 重写有什么缺点
*****************************************************************
　　　对所有的 URL 使用 URL 重写，包括超链接， form 的 action ，和重定向的 URL 。每个引用你的站点的 URL ，以及那些返回给用户的 URL( 即使通过间接手段，比如服务器重定向中的 Location 字段 ) 都要添加额外的信息。
　　　这意味着在你的站点上不能有任何静态的 HTML 页面 ( 至少静态页面中不能有任何链接到站点动态页面的链接 ) 。因此，每个页面都必须使用 servlet 或 JSP 动态生成。即使所有的页面都动态生成，如果用户离开了会话并通过书签或链接再次回来，会话的信息都会丢失，因为存储下来的链接含有 错误的标识信息－该 URL 后面的 SESSION ID 已经过期了。　　
***************************************************************

十七、使用隐藏的表单域有什么缺点
*******************************************************************
    仅当每个页面都是有表单提交而动态生成时，才能使用这种方法。单击常规的 <A HREF..> 超文本链接并不产生表单提交，因此隐藏的表单域不能支持通常的会话跟踪，只能用于一系列特定的操作中，比如在线商店的结账过程
*****************************************************************

十八、会话跟踪的基本步骤
*********************************************************************
1 ．访问与当前请求相关的会话对象
2 ．查找与会话相关的信息
3 ．存储会话信息
4 ．废弃会话数据
*************************************************************

十九、 getSession()/getSession(true) 、 getSession(false) 的区别
**************************************************************
getSession()/getSession(true) ：当 session 存在时返回该 session ，否则新建一个 session 并返回该对象
getSession(false) ：当 session 存在时返回该 session ，否则不会新建 session ，返回 null
****************************************************************

二十、如何将信息于会话关联起来
***************************************************************
　　 setAttribute 会替换任何之前设定的值；如果想要在不提供任何代替的情况下移除某个值，则应使用 removeAttribute 。这个方法会触发所有实现了 HttpSessionBindingListener 接口的值的 valueUnbound
方法。
**************************************************************

二十一、会话属性的类型有什么限制吗
***************************************************************
通常会话属性的类型只要是 Object 就可以了。除了 null 或基本类型，如 int,double,boolean 。
如果要使用基本类型的值作为属性，必须将其转换为相应的封装类对象
****************************************************************

二十二、如何废弃会话数据
**************************************************************
A ．只移除自己编写的 servlet 创建的数据：
   调用 removeAttribute(“key”) 将指定键关联的值废弃
B ．删除整个会话 ( 在当前 Web 应用中 ) ：
   调用 invalidate ，将整个会话废弃掉。这样做会丢失该用户的所有会话数据，而非仅仅由我们
servlet 或 JSP 页面创建的会话数据
C ．将用户从系统中注销并删除所有属于他 ( 或她 ) 的会话
   调用 logOut ，将客户从 Web 服务器中注销，同时废弃所有与该用户相关联的会话 ( 每个 Web 应用至多一个 ) 。这个操作有可能影响到服务器上多个不同的 Web 应用
*************************************************************

二十三、使用 isNew 来判断用户是否为新旧用户的错误做法
*************************************************************
public boolean isNew() 方法如果会话尚未和客户程序 ( 浏览器 ) 发生任何联系，则这个方法返回 true ，这一般是因为会话是新建的，不是由输入的客户请求所引起的。
但如果 isNew 返回 false ，只不过是说明他之前曾经访问该 Web 应用，并不代表他们曾访问过我们的 servlet 或 JSP 页面。
因为 session 是与用户相关的，在用户之前访问的每一个页面都有可能创建了会话。因此 isNew 为 false 只能说用户之前访问过该 Web 应用， session 可以是当前页面创建，也可能是由用户之前访问过的页面创建的。
正确的做法是判断某个 session 中是否存在某个特定的 key 且其 value 是否正确
***************************************************************

二十四、 Cookie 的过期和 Session 的超时有什么区别
***************************************************************
会话的超时由服务器来维护，它不同于 Cookie 的失效日期。首先，会话一般基于驻留内存的 cookie
不是持续性的 cookie ，因而也就没有截至日期。即使截取到 JSESSIONID cookie ，并为它设定一个失效日期发送出去。浏览器会话和服务器会话也会截然不同。
*******************************************************

二十五、 session cookie 和 session 对象的生命周期是一样的吗
********************************************************
当用户关闭了浏览器虽然 session cookie 已经消失，但 session 对象仍然保存在服务器端
**************************************************************

二十六、是否只要关闭浏览器， session 就消失了
*************************************************************
程序一般都是在用户做 log off 的时候发个指令去删除 session ，然而浏览器从来不会主动在关闭之前通知服务器它将要被关闭，因此服务器根本不会有机会知道浏览器已经关闭。服务器会一直保留这个会话对象直到它处于非活动状态超过设定的间隔为止。
之所以会有这种错误的认识，是因为大部分 session 机制都使用会话 cookie 来保存 session id ，而关闭浏览器后这个 session id 就消失了，再次连接到服务器时也就无法找到原来的 session 。
如果服务器设置的 cookie 被保存到硬盘上，或者使用某种手段改写浏览器发出的 HTTP 请求报头，把原来的 session id 发送到服务器，则再次打开浏览器仍然能够找到原来的 session 。
恰恰是由于关闭浏览器不会导致 session 被删除，迫使服务器为 session 设置了一个失效时间，当距离客户上一次使用 session 的时间超过了这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把 session 删除以节省存储空间。
　　由此我们可以得出如下结论：
　　关闭浏览器，只会是浏览器端内存里的 session cookie 消失，但不会使保存在服务器端的 session 对象消失，同样也不会使已经保存到硬盘上的持久化 cookie 消失。
*******************************************************************


二十七、打开两个浏览器窗口访问应用程序会使用同一个 session 还是不同的 session
***************************************************************
通常 session cookie 是不能跨窗口使用的，当你新开了一个浏览器窗口进入相同页面时，系统会赋予你一个新的 session id ，这样我们信息共享的目的就达不到了。
此时我们可以先把 session id 保存在 persistent cookie 中 ( 通过设置 session 的最大有效时间 ) ，然后在新窗口中读出来，就可以得到上一个窗口的 session id 了，这样通过 session cookie 和 persistent cookie 的结合我们就可以实现了跨窗口的会话跟踪。
***************************************************************

二十八、如何使用会话显示每个客户的访问次数
******************************************************
由于客户的访问次数是一个整型的变量，但 session 的属性类型中不能使用 int ， double ， boolean 等基本类型的变量，所以我们要用到这些基本类型的封装类型对象作为 session 对象中属性的值
　　但像 Integer 是一种不可修改 (Immutable) 的数据结构：构建后就不能更改。这意味着每个请求都必须创建新的 Integer 对象，之后使用 setAttribute 来代替之前存在的老的属性的值。例如：
HttpSession session = request.getSession();
SomeImmutalbeClass value = (SomeImmutableClass)session .getAttribute(“SomeIdentifier”);
if (value= =null){
    value = new SomeImmutableClass(…); 　 // 新创建一个不可更改对象
}else{
    value = new SomeImmutableClass(calculatedFrom(value)); // 对 value 重新计算后创建新的对象
}
session .setAttribute(“someIdentifier”,value); // 使用新创建的对象覆盖原来的老的对象
***************************************************************

二十九、如何使用会话累计用户的数据
*************************************************************
使用可变的数据结构，比如数组、 List 、 Map 或含有可写字段的应用程序专有的数据结构。通过这种方式，除非首次分配对象，否则不需要调用 setAttribute 。例如

HttpSession session = request.getSession();
SomeMutableClass value = (SomeMutableClass)session .getAttribute(“someIdentifier”);
if(value = = null){
    value = new SomeMutableClass(…);
    session .setAttribute(“someIdentifier”,value);
}else{
    value.updateInternalAttribute(…);     // 如果已经存在该对象则更新其属性而不需重新设置属性
}
****************************************************************

三十、不可更改对象和可更改对象在会话数据更新时的不同处理
*****************************************************************
不可更改对象因为一旦创建之后就不能更改，所以每次要修改会话中属性的值的时候，都需要
调用 setAttribute(“someIdentifier”,newValue) 来代替原有的属性的值，否则属性的值不会被更新
可更改对象因为其自身一般提供了修改自身属性的方法，所以每次要修改会话中属性的值的时
候，只要调用该可更改对象的相关修改自身属性的方法就可以了。这意味着我们就不需要调
用 setAttribute 方法了