【转】关于Session的若干

• url 中jsessionid引起的一个问题

XX系统登录之后，偶尔在用户那会出现这个现象：

登录的逻辑是这样的：登陆主界面之后，在主界面html执行到最后的时候，使用windows.open 打开一个弹出窗口，去服务器取一些需要的数据。
但是偶尔用户那会出现弹出窗口又定位到登陆窗口了（summer中使用filter对请求过滤，发现没有登陆的话会重新定位到登陆窗口）。
这里明明是的刚登陆的程序，却出现没有登陆的现象。。这个现象在用户那一直就存在，一直也没找到原因。
今天在和三期应服推广人员的沟通中无意了解到，用户习惯使用给登陆界面建立一个桌面快捷方式，一般操作如下：
在ie地址栏输入“http://localhost:8080/spxt”，这个时候请求完成之后定位到了登陆页面，但是ie地址栏已经变成
“http://localhost:8080/spxt/common/summer/jsp/login/register03.jsp;jsessionid=CA0CA7E455535994E523B01357B42214”
此时直接在这个ie窗口登陆是没有问题的。而用户一般都是在这个页面点右键，选择创建快捷方式，
这个时候就有一个问题，用户的快捷方式超链接实际上指向的是后面那个带有jsessionid的很长很长的url。
如果此时从桌面点击这个超链接的快捷方式打开ie进行登陆，就很容易复现文章开始的那个截图现象了，如果我修改快捷方式属性，把超链接的
sessionid去掉就没有问题了。（这里描述不是很准确，比如重启一次tomcat的话就又不会复现了）。
后来在后台打印每次使用的sessionid，发现如果从快捷方式登陆的话，真正的登录session就是jsessionid所代表的那个 session，而后来ajax
请求的是和服务器新建了连接，发现session没有登陆信息就定位到登陆页面了。
这里在服务器端“可能”是产生两个session的概念：一个是本次真正登录的session；另外是一个空的session。而在ajax异步请求的时候，
实际上用的就是后面这个空的session，这样发现没有登陆就重新定位到登陆页面了？
后面原因的分析完全是自己的猜测，具体望大家指教一下：）
解决问题可以这样：1、帮用户把那个快捷方式的jsessionid去掉。
2、写一个filter，对于是登陆请求的，把jsessionid去掉。
ps：以上问题对于收藏夹存在同样问题。
看了帖子终于明白jsessionid是怎么来的了~多谢
在struts的org.apache.struts.action.RequestProcessor.processForwardConfig() 中找到了如下代码：
response.sendRedirect(response.encodeRedirectURL(uri));
不过感觉一般情况还是不要去掉jsessionid比较好，对于特殊情况的需要特殊去掉，基本还是利大于弊。

本文出处：http://www.blogjava.net/midstr/archive/2009/02/25/256596.html

• 由JSESSIONID谈cookie与SESSION的区别和联系

在一些投票之类的场合，我们往往因为公平的原则要求每人只能投一票，在一些WEB开发中也有类似的情况，这时候我们通常会使用COOKIE来实现，例如如下的代码：
< % cookie[]cookies = request.getCookies();
if (cookies.lenght == 0 || cookies == null)
doStuffForNewbie();
//没有访问过
}

else
{
doStuffForReturnVisitor(); //已经访问过了
}

% >

这是很浅显易懂的道理，检测COOKIE的存在，如果存在说明已经运行过写入COOKIE的代码了，然而运行以上的代码后，无论何时结果都是执行 doStuffForReturnVisitor()，通过控制面板-Internet选项-设置-察看文件却始终看不到生成的cookie文件，奇怪，代码明明没有问题，不过既然有cookie，那就显示出来看看。
cookie[]cookies = request.getCookies();
if (cookies.lenght == 0 || cookies == null)
out.println("Has not visited this website");
}

else
{
for (int i = 0; i < cookie.length; i++)
{
out.println("cookie name:" + cookies[i].getName() + "cookie value:" +
cookie[i].getValue());
}
}

运行结果:
cookie name:JSESSIONID cookie value:KWJHUG6JJM65HS2K6 为什么会有cookie呢,大家都知道，http是无状态的协议，客户每次读取web页面时，服务器都打开新的会话，而且服务器也不会自动维护客户的上下文信息，那么要怎么才能实现网上商店中的购物车呢，session就是一种保存上下文信息的机制，它是针对每一个用户的，变量的值保存在服务器端，通过 SessionID来区分不同的客户,session是以cookie或URL重写为基础的，默认使用cookie来实现，系统会创造一个名为 JSESSIONID的输出cookie，我们叫做session cookie,以区别persistent cookies,也就是我们通常所说的cookie,注意session cookie是存储于浏览器内存中的，并不是写到硬盘上的，这也就是我们刚才看到的JSESSIONID，我们通常情是看不到JSESSIONID的，但是当我们把浏览器的cookie禁止后，web服务器会采用URL重写的方式传递Sessionid，我们就可以在地址栏看到 sessionid=KWJHUG6JJM65HS2K6之类的字符串。
明白了原理，我们就可以很容易的分辨出persistent cookies和session cookie的区别了，网上那些关于两者安全性的讨论也就一目了然了，session cookie针对某一次会话而言，会话结束session cookie也就随着消失了，而persistent cookie只是存在于客户端硬盘上的一段文本（通常是加密的），而且可能会遭到cookie欺骗以及针对cookie的跨站脚本攻击，自然不如 session cookie安全了。
通常session cookie是不能跨窗口使用的，当你新开了一个浏览器窗口进入相同页面时，系统会赋予你一个新的sessionid，这样我们信息共享的目的就达不到了，此时我们可以先把sessionid保存在persistent cookie中，然后在新窗口中读出来，就可以得到上一个窗口SessionID了，这样通过session cookie和persistent cookie的结合我们就实现了跨窗口的session tracking（会话跟踪）。
在一些web开发的书中，往往只是简单的把 Session和cookie作为两种并列的http传送信息的方式，session cookies位于服务器端，persistent cookie位于客户端，可是session又是以cookie为基础的，明白的两者之间的联系和区别，我们就不难选择合适的技术来开发web service了。

----------------------------------------------------------------------------------------------------------------------

cookie和session机制之间的区别与联系

　　具体来说cookie机制采用的是在客户端保持状态的方案。它是在用户端的会话状态的存贮机制，他需要用户打开客户端的cookie支持。 cookie的作用就是为了解决HTTP协议无状态的缺陷所作的努力.
　而session机制采用的是一种在客户端与服务器之间保持状态的解决方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的。而session提供了方便管理全局变量的方式

　　session是针对每一个用户的，变量的值保存在服务器上，用一个sessionID来区分是哪个用户session变量,这个值是通过用户的浏览器在访问的时候返回给服务器，当客户禁用cookie时，这个值也可能设置为由get来返回给服务器。

　　就安全性来说：当你访问一个使用session 的站点，同时在自己机子上建立一个cookie，建议在服务器端的SESSION机制更安全些.因为它不会任意读取客户存储的信息。

　　正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的 cookie

　　从网络服务器观点看所有HTTP请求都独立于先前请求。就是说每一个HTTP响应完全依赖于相应请求中包含的信息状态管理机制克服了HTTP的一些限制并允许网络客户端及服务器端维护请求间的关系。在这种关系维持的期间叫做会话(session)。

　　Cookies是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器。IETF RFC 2965 HTTP State Management Mechanism 是通用cookie规范。网络服务器用HTTP头向客户端发送cookies，在客户终端，浏览器解析这些cookies并将它们保存为一个本地文件，它会自动将同一服务器的任何请求缚上这些cookies

----------------------------------------------------------------------------------------------------

cookie和session机制区别与联系

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

cookie机制。正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。而cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围大于等于将要请求的资源所在的位置，则把该 cookie附在请求资源的HTTP请求头上发送给服务器。
cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围。若不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，关闭浏览器窗口，cookie就消失。这种生命期为浏览器会话期的cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。若设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些 cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的 cookie，不同的浏览器有不同的处理方式
session机制。session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为session id），如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（检索不到，会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。
保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于 SEEESIONID。但cookie可以被人为的禁止，则必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。
经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面。还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如：
<form name="testform" action="/xxx">
<input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764">
<input type="text">
</form>
实际上这种技术可以简单的用对action应用URL重写来代替。

• url中的jsessionid解释

（1）
这是一个保险措施
因为Session默认是需要Cookie支持的
但有些客户浏览器是关闭Cookie的
这个时候就需要在URL中指定服务器上的session标识,也就是5F4771183629C9834F8382E23BE13C4C
用一个方法(忘了方法的名字)处理URL串就可以得到这个东西
这个方法会判断你的浏览器是否开启了Cookie,如果他认为应该加他就会加上去
（2）
链接1：wapbrowse.jsp?curAlbumID=9 ；
链接2:wapbrowse.jsp;jsessionid=5AC6268DD8D4D5D1FDF5D41E9F2FD960?curAlbumID=9；
这两个链接是从模拟器运行时生成的source中拷贝过来的，两个链接都是指向wapbrowse.jsp,链接1由于不包含jsessionid,所以在wapbrowse.jsp中变量为null,通过链接2打开 wapbrowse.jsp可以正常访问session 变量
（3）
URL重写功能,为了防止一些用户把Cookie禁止而无法使用session而设置的功能.jsessionid后面的一长串就是你服务器上的session的ID号,这样无需cookie也可以使用session.
（4）
http本身是无session的，无法跟踪客户端的信息，换句话说：http协议不管是谁联接自己。
为了实现session，必须有浏览器支持。浏览器可以用cookie存储session，这是最通用的做法。
但是，如果我自己写一个完全符合http协议的浏览器，但是不配合服务器的session要求，那么服务器就无法产生session。
好在现在的浏览器都支持session要求，即使关闭了cookie，浏览器也会向服务器传递sessionid，这个id是存储在浏览器的内存空间中的，不保存在硬盘cookie中。
（5）
sessionid是作为一个临时cookie放在浏览器端的。
session的具体信息放在服务器端。
每次浏览器发出的请求，都会在http header里 带上 sessionid来标识自己。
既然用Struts，顺便再把JSTL用上，
下面一个非常有用的标签：
清单 12. 操作的语法
var="name" scope="scope">
...
URL 重写是由 操作自动执行的。如果 JSP 容器检测到一个存储用户当前会话标识的 cookie，那么就不必进行重写。但是，如果不存在这样的 cookie，那么 生成的所有 URL 都会被重写以编码会话标识。注：如果在随后的请求中存在适当的 cookie，那么 将停止重写 URL 以包含该标识。
参考：http://www-900.ibm.com/developerWorks/cn/java/j-jstl0318 /index.shtml
（6）
方法一：url中紧跟servlet/jsp文件名加;jsessionid=sessionId，其中sessionId由HttpSession.getId()得到，如http://localhost:8080/aaa/bbb.jsp;jsessionid=saldjfsdflsaeir234?para=1¶2=2
方法二：在application(ServletContext)里保存一个session管理器HashMap:sessionId--- sessionRef，这样可以在所有的servlet/jsp里调用，这需要在url里将sessionId以参数形式传递，如http: //localhost:8080/aaa/bbb.jsp?sessionId=saldjfsdflsaeir234?para=1¶2=2，在服务器端用request.getParameter("sessionId")获取
（7）
session是在服务器端保存。服务器根据url请求中的session_id来查找对应的session。
以一个bbs为例，网站需要根据每个请求url获取用户的信息，如果以cookie方式，用户信息全部是存放在cookie中的，这样可能会不安全；如果以session方式，用户信息可以存放在服务器端，服务器只要从http请求中得到session_id，就可以得到存放在session中的用户信息了，这样安全性比较高。session在服务器中的表现方式依服务器而定，可能是写到临时文件中，也可能直接放在内存中。
服务器从http请求中得到session_id的方式有两种：cookie和url重写。如果客户端启用cookie，那么 session_id可以保存在cookie中；如果禁用cookie，就用url重写方式，在url中添加.jsessionid=xxxxx参数部分，服务器会试图从url中得到.jsessionid参数作为session_id.
（8）
cookie 是保存在客户端的文本格式数据，session是客户端登录到应用，由服务器为该客户端建立的唯一的标识，可以在session里面保存该客户端的数据比如说用户帐号。
一般cookie可以用来保存你的登录帐号和密码，在你登录到应用服务上，自动添加到登录界面或直接发送到服务器上进行登录，这就是你经常能在论坛上看到的你的登录信息保存一年的选项 的实现方式
（9）
在http的报文格式里面cookie和session是在同一个包文位置上的
如果ie发现包文里面包含cookie/session的信息的话，他会根据安全级别来决定是否保存相关信息，比如，如果安全机制允许使用 cookie那么ie将把cookie的信息保存到临时文件里面，每次在请求服务器文件的时候会把收到的session的信息加入到请求的报文里面，这就是session保存信息的原理。如果安全机制不允许使用cookie的话，虽然ie收到了cookie和session的信息，那么cookie的信息不会被写入临时文件，当ie再次请求服务器文件的时候，也不会把收到的session的信息加入到请求报文里面，服务器就无法知道session的信息了。

本文出处：http://sizhefang.javaeye.com/blog/25294