BlogJava-疯狂-随笔分类-java安全

关于tomcat和sessionCookieName和SESSION_PARAMETER_NAME以及disableURLRewriting参数原理和使用

疯狂 — Mon, 24 Dec 2012 07:16:00 GMT

摘要: 关于tomcat和sessionCookieName和SESSION_PARAMETER_NAME以及disableURLRewriting参数原理和使用阅读全文

疯狂 2012-12-24 15:16 发表评论

数字证书原理(转)

疯狂 — Tue, 24 Jul 2012 02:35:00 GMT

摘要: 数字证书原理文中首先解释了加密解密的一些基础知识和概念，然后通过一个加密通信过程的例子说明了加密算法的作用，以及数字证书的出现所起的作用。接着对数字证书做一个详细的解释，并讨论一下windows中数字证书的管理，最后演示使用makecert生成数字证书。如果发现文中有错误的地方，或者有什么地方说得不够清楚，欢迎指出！ 1、基础知识 ... 阅读全文

疯狂 2012-07-24 10:35 发表评论

OAuth简介

疯狂 — Fri, 29 Jul 2011 03:19:00 GMT

OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。

OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要分享他们的访问许可或他们数据的所有内容。

OAuth是OpenID的一个补充，但是完全不同的服务。

认证和授权过程

在认证和授权的过程中涉及的三方包括：

服务提供方，用户使用服务提供方来存储受保护的资源，如照片，视频，联系人列表。
用户，存放在服务提供方的受保护的资源的拥有者。
客户端，要访问服务提供方资源的第三方应用，通常是网站，如提供照片打印服务的网站。在认证过程之前，客户端要向服务提供者申请客户端标识。

使用OAuth进行认证和授权的过程如下所示:

用户访问客户端的网站，想操作用户存放在服务提供方的资源。
客户端向服务提供方请求一个临时令牌。
服务提供方验证客户端的身份后，授予一个临时令牌。
客户端获得临时令牌后，将用户引导至服务提供方的授权页面请求用户授权。在这个过程中将临时令牌和客户端的回调连接发送给服务提供方。
用户在服务提供方的网页上输入用户名和密码，然后授权该客户端访问所请求的资源。
授权成功后，服务提供方引导用户返回客户端的网页。
客户端根据临时令牌从服务提供方那里获取访问令牌。
服务提供方根据临时令牌和用户的授权情况授予客户端访问令牌。
客户端使用获取的访问令牌访问存放在服务提供方上的受保护的资源。

新浪oauth认证说明：
http://open.weibo.com/wiki/Oauth
豆瓣oauth认证：
http://www.douban.com/service/apidoc/auth

疯狂 2011-07-29 11:19 发表评论

tomcat https

疯狂 — Sat, 25 Jun 2011 15:06:00 GMT

HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密

的详细内容就需要SSL
　　SSL协议的握手过程
SSL 协议既用到了公钥加密技术又用到了对称加密技术，对称加密技术虽然比公钥加密技术的速度快，可是公钥加密技术提供了更好的身份认证技术。SSL 的握手协议非常有效的让客户和服

务器之间完成相互之间的身份认证，其主要过程如下：　　
①客户端的浏览器向服务器传送客户端 SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。　　
②服务器向客户端传送 SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。　　
③客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的 CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字

签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。　　
④用户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后将加密后的“预主密码”传给服务器。　　
⑤如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传

给服务器。　　
⑥如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA 是否可靠，发行CA

的公钥能否正确解开客户证书的发行 CA 的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的

“预主密码”，然后执行一系列步骤来产生主通讯密码（客户端也将通过同样的方法产生相同的主通讯密码）。　　
⑦服务器和客户端用相同的主密码即“通话密码”，一个对称密钥用于 SSL 协议的安全数据通讯的加解密通讯。同时在 SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何

变化。　　
⑧客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。　　
⑨服务器向客户端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。　　
⑩SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

下面是在tomcat下实现https，使用jdk自带的keytool工具生成自签名证书。

1 生成keystore文件，keystore文件用来存储密钥和证书
keystore的详细参数可使用可使用keystore命令查看。

keytool -genkeypair -keyalg rsa -keysize 2048 -sigalg sha1withrsa -validity 3600 -alias www.joe.com -keystore e:\ssl\joe.keystore
输入keystore密码：
再次输入新密码:
您的名字与姓氏是什么？
[Unknown]： www.joe.com
您的组织单位名称是什么？
[Unknown]： joe
您的组织名称是什么？
[Unknown]： joe
您所在的城市或区域名称是什么？
[Unknown]： bj
您所在的州或省份名称是什么？
[Unknown]： bj
该单位的两字母国家代码是什么
[Unknown]： cn
CN=www.joe.com, OU=joe, O=joe, L=bj, ST=bj, C=cn 正确吗？
[否]： y

输入<www.joe.com>的主密码
        （如果和 keystore 密码相同，按回车）：
2 导出自签名证书。正是平台需要导出csr文件并去权威的ca认证机构获取受信任证书，一般是收费的。
   keytool -exportcert -alias www.joe.com -keystore e:\ssl\joe.keystore -file e:\ssl\joe.cer -rfc
输入keystore密码：
保存在文件中的认证
下面配置tomcat(server.xml)使其支持https.
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS" keystoreFile="conf/joe.keystore" keystorePass="123456"/>

3 修改操作系统host文件，添加127.0.0.1 www.joe.com

4 新建web应用httpstest
并添加indexjsp:

    <%
     for(Enumeration en = request.getAttributeNames();en.hasMoreElements();){
    String name = (String)en.nextElement();
    out.println(name);
    out.println("="+request.getAttribute(name));
    out.println();
     }
    %>

5 为了让浏览器信任我们的证书，需要在浏览器导入我们的证书为信任根证书。
6 访问：https://www.joe.com/httpstest
输出：
javax.servlet.request.ssl_session =4e05eb849ac41a45b56725488b68c28cc8c2ea94e2ec599852e1665297b2822b
javax.servlet.request.key_size =128
javax.servlet.request.cipher_suite =SSL_RSA_WITH_RC4_128_MD5 (通讯的加密信息，由浏览器和服务器协商确定)。

疯狂 2011-06-25 23:06 发表评论

WEB应用中的身份验证(1)--基本身份验证BASIC authorization method

疯狂 — Tue, 22 Mar 2011 10:33:00 GMT

在任何一种WEB应用开发中，不论大中小规模的，每个开发者都会遇到一些需要保护程序数据的问题，涉及到用户的LOGIN ID和PASSWORD。那么如何执行验证方式更好呢？实际上，有很多方式来实现。在本文里，我们不会把所有的验证方法都考虑到，我们的目的是让你学会如何以最简单最方便的验证方法来完成。下面将讨论基本验证方式之一（BASIC authorization method）

要搭建整个流程需要四个阶段：

一、建立测试用数据库
        我们这里用Mysql进行测试，其他数据库完全一样。
    1、创建用户表
            CREATE TABLE users (
                  id int(11) NOT NULL auto_increment,
                   username varchar(20) NOT NULL,
                   password varchar(20) NOT NULL,
                   PRIMARY KEY (id)
               )

    2、创建权限表（此事例中用不到）
           CREATE TABLE roles(
                   id int(11) NOT NULL auto_increment,
                   rolename varchar(20) NOT NULL,
                   PRIMARY KEY (id)
              )

    3、创建用户－权限对应表
       CREATE TABLE user_roles (
          id int(11) NOT NULL auto_increment,
          username varchar(20) NOT NULL,
          rolename varchar(20) NOT NULL,
          PRIMARY KEY (id)
        )

    4、插入数据
       insert into users(username,password) values('zhangdongyu', 'loveyuanyuan')
       insert into roles(rolename) values('manager')
       insert into user_roles(username,rolename) values('zhangdongyu', 'manager')

二、修改${tomcat}\conf\server.xml
  找到


    在上面这句话下面添加一下内容：
           className="org.apache.catalina.realm.JDBCRealm"
      debug="99"
      driverName="org.gjt.mm.mysql.Driver"
      connectionURL="jdbc:mysql://localhost/weblogin"
      connectionName="root"
          connectionPassword="123"
         userTable="users"
          userNameCol="username"
          userCredCol="password"
          userRoleTable="user_roles"
          roleNameCol="rolename"
    />

三、创建工程
在Eclipse创建一个web工程sercurityTest，在WebRoot下面创建一个文件夹admin(也可在里面建立几个文件)

  在web.xml文件中添加以下片段：


       Web Demo
       /admin/*


       manager



      BASIC
      Web Demo

四、重启Tomcat，使设置生效

总结测试：
  通过上面的四部分配置，当你再次访问程序中受保护的地址，如:http://localhost/sercurityTest/admin时
  会弹出验证对话框，让你输入用户名和密码，只有输入库中的用户名密码并且该用户有manager权限时才能进
  入受保护目录。

转载自：http://blog.csdn.net/swengineer/archive/2006/12/01/1424020.aspx

疯狂 2011-03-22 18:33 发表评论

Cookie和Session

疯狂 — Thu, 09 Sep 2010 05:26:00 GMT

一、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     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已经过期了。　　
************************************************************************

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

十八、会话跟踪的基本步骤
************************************************************************
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方法了

************************************************************************
2.cookies的属性有：Domain(域)：哪个站点发的哪个站点拿走
                   Expires:是否过期
                   Haskeys:是否包含关键
                   path:存放的路径
                   secure:是否安全
注：－－－cookies的设置在 sever端设置，路径与域一起构成cookie的作用范围?
这个是什么意思的啊？为什么会是在服务器端进行设置的呢？
    若不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，关闭浏览器窗口，cookie就消失。这种生命期为浏览器会话期的cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。若设置了过期时间，浏览器就会把cookie 保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式
IE与FF的区别哦！FF是共享的而IE当打开不同的窗口的时候是不共享的
3.session(会话)：适用于同一客户在一个站点，不同页面上的浏览；适用于同一客户在一个页面上，不断的刷新。
6.当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为session id），如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（检索不到，会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。

IE中:
有效的窗中包括
1.Session对象只在建立Session对象的窗口中有效。
2.在建立Session对象的窗口中新开链接的窗口
无效的窗口包括
1.直接启动IE浏览器的窗口
2.不是在建立Session对象的窗口中新开链接的窗口

***********************************************************************
cookie的内容主要包括：名字，值，过期时间，路径和域。
其中,

域可以指定某一个域比如.google.com，相当于总店招牌，比如宝洁公司，也可以指定一个域下的具体某台机器比如www.google.com或者froogle.google.com，可以用飘柔来做比。
路径就是跟在域名后面的URL路径，比如/或者/foo等等，可以用某飘柔专柜做比。
路径与域合在一起就构成了cookie的作用范围。
如果不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览器会话期的 cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。

存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式。对于IE，在一个打开的窗口上按Ctrl-N（或者从文件菜单）打开的窗口可以与原窗口共享，而使用其他方式新开的IE进程则不能共享已经打开的窗口的内存cookie；对于Mozilla Firefox0.8，所有的进程和标签页都可以共享同样的cookie。一般来说是用javascript的window.open打开的窗口会与原窗口共享内存cookie。浏览器对于会话cookie的这种只认cookie不认人的处理方式经常给采用session机制的web应用程序开发者造成很大的困扰。

[经典的语录]

下面就是一个goolge设置cookie的响应头的例子
HTTP/1.1 302 Found
Location: http://www.google.com/intl/zh-CN/
Set-Cookie: PREF=ID=0565f77e132de138:NW=1:TM=1098082649:LM=1098082649:S=KaeaCFPo49RiA_d8; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Content-Type: text/html

到时候我们的域就要设置为domain=.*****.cn path=/

session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

四、理解session机制
session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为session id，如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。

保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于 SEEESIONID，而。比如weblogic对于web应用程序生成的 cookie，JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是JSESSIONID。

由于cookie可以被人为的禁止，必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面，附加方式也有两种，一种是作为URL路径的附加信息，表现形式为http://..... /xxx;jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
另一种是作为查询字符串附加在URL后面，表现形式为http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
这两种方式对于用户来说是没有区别的，只是服务器在解析的时候处理的方式不同，采用第一种方式也有利于把session id的信息和正常程序参数区分开来。
为了在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。

另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如下面的表单

在被传递给客户端之前将被改写成

这种技术现在已较少应用，笔者接触过的很古老的iPlanet6(SunONE应用服务器的前身)就使用了这种技术。
实际上这种技术可以简单的用对action应用URL重写来代替。

在谈论session机制的时候，常常听到这样一种误解“只要关闭浏览器，session就消失了”。其实可以想象一下会员卡的例子，除非顾客主动对店家提出销卡，否则店家绝对不会轻易删除顾客的资料。对session来说也是一样的，除非程序通知服务器删除一个session，否则服务器会一直保留，程序一般都是在用户做log off的时候发个指令去删除session。然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所以会有这种错觉，是大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个session id就消失了，再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的 HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session。

恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为seesion设置了一个失效时间，当距离客户端上一次使用session的时间超过这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session删除以节省存储空间。

[写得太精彩了。感受太深了！]

1、session在何时被创建
一个常见的误解是以为session在有客户端访问时就被创建，然而事实是直到某server端程序调用 HttpServletRequest.getSession(true)这样的语句时才被创建，注意如果JSP没有显示的使用 <%@page session="false"%> 关闭session，则JSP文件在编译成Servlet时将会自动加上这样一条语句HttpSession session = HttpServletRequest.getSession(true);这也是JSP中隐含的session对象的来历。

由于session会消耗内存资源，因此，如果不打算使用session，应该在所有的JSP中关闭它。

2、session何时被删除
综合前面的讨论，session在下列情况下被删除a.程序调用HttpSession.invalidate();或b.距离上一次收到客户端发送的session id时间间隔超过了session的超时设置;或c.服务器进程被停止（非持久session）

3、如何做到在浏览器关闭时删除session
严格的讲，做不到这一点。可以做一点努力的办法是在所有的客户端页面里使用javascript代码window.oncolose来监视浏览器的关闭动作，然后向服务器发送一个请求来删除session。但是对于浏览器崩溃或者强行杀死进程这些非常规手段仍然无能为力。

7、开两个浏览器窗口访问应用程序会使用同一个session还是不同的session
参见第三小节对cookie的讨论，对session来说是只认id不认人，因此不同的浏览器，不同的窗口打开方式以及不同的cookie存储方式都会对这个问题的答案有影响。

8、如何防止用户打开两个浏览器窗口操作导致的session混乱
这个问题与防止表单多次提交是类似的，可以通过设置客户端的令牌来解决。就是在服务器每次生成一个不同的id返回给客户端，同时保存在session里，客户端提交表单时必须把这个id也返回服务器，程序首先比较返回的id与保存在 session里的值是否一致，如果不一致则说明本次操作已经被提交过了。［对不起你已经投过票了！可以这样来进行控制的哦］

八、总结
session机制本身并不复杂，然而其实现和配置上的灵活性却使得具体情况复杂多变。这也要求我们不能把仅仅某一次的经验或者某一个浏览器，服务器的经验当作普遍适用的经验，而是始终需要具体情况具体分析。

文章出处：DIY部落(http://www.diybl.com/course/3_program/java/javashl/20090306/158662.html)

************************************************************************

关于COOKIE和SESSION的关系，一直没搞清楚。网上一搜COOKIE，普遍都有会话COOKIE和持久COOKIE的概念。

rubyeye的博客里有这样的解释，我把部分贴过来。（http://rubyeye.javaeye.com/blog/196117）

引用
当你第一次访问一个网站的时候,网站服务器会在响应头内加上
Set-Cookie:PHPSESSID=nj1tvkclp3jh83olcn3191sjq3(php服务器),或Set-Cookie JSESSIONID=nj1tvkclp3jh83olcn3191sjq3(java服务器)信息,此信息是服务器随机生成的,放在服务器内存里,为了标识唯一的客户端用户,内容不会重复,这就是sessionid.
   当浏览器得到这个sessionid会将它放在自己的进程内存里,这里不同的浏览器会有所不同,IE进程间不能共享这个sessionid,也就是新开一个IE将不能共享这个sessionid;而Firefox进程间可以共享.然后你继续发请求给这个网站的时候,浏览器就会把这个sessionid放在请求头里发送给该服务器了,这样服务器得到sessionid后再和自己内存里存放的sessionid对比锁定客户端,从而区分不同客户端,完成会话.
   可以看出如果用这种方式,当用户在会话的过程中关闭浏览器结束进程,则这个sessionid将消失,如果用户又打开浏览器想继续这次会话的时候,就会因为发送的请求中没有这个sessionid而使服务器无法辨别该把那个session信息给他,注意(这个时候服务器端的sessionid和sessionid所指向的session都还存在,只是没有正确的sessionid和它匹配而占用服务器内存,只有session过期或服务器重启才释放内存).
   上面这种方式叫会话cookie,把cookie放在浏览器内存里,只能在这个浏览器的内存范围里完成会话,是一种不长久的方式,为了能长久会话,就出现了持久化cookie,把cookie固化在用户的计算机上,现在的cookie不单单能存放sessionid,还能放用户信息,样式表信息等.
   如果用户禁止了所有cookie的使用,那么会话cookie和持久化cookie都不能用了,有个方案也可以解决问题,就是URL重写,这里要说下的就是URL重写只能实现会话cookie的效果,持久会话实现不了.

刚开始理解时，我也认为会有持久和会话这两种COOKIE。我认为，
会话COOKIE就是用来存放SESSIONID的，并且只存在于浏览器内存，浏览器关闭后会话COOKIE就被删除；
持久COOKIE就是用来存放其它信息，并且是在我们的本地硬盘里能看到的那种COOKIE。

然后我写了个SERVLET试了一下。

Java代码
public void service(HttpServletRequest request, HttpServletResponse response) throws IOException {

    Cookie cookie = null;

    PrintWriter out = response.getWriter();
    out.println("");

    Cookie[] cookies = request.getCookies();

    // 如果没有COOKIE，新建一个COOKIE
    if (cookies == null) {

        out.println("cookies is null.
");

        cookie = new Cookie("new", "1");

        response.addCookie(cookie);

    } else {

        out.println("cookies is not null.
");

        for (int i = 0; i < cookies.length; i++) {

            cookie = cookies[i];

            out.println("cookie" + i + " name: " + cookie.getName() + "
");
        }
    }

    HttpSession session = request.getSession();

    if (session == null) {
        out.println("session is null.
");

    } else {
        out.println("session is not null.
");
        out.println("session id: " + session.getId() + "
");
    }

    out.println("");
}
public void service(HttpServletRequest request, HttpServletResponse response) throws IOException {

Cookie cookie = null;

PrintWriter out = response.getWriter();
out.println("");

Cookie[] cookies = request.getCookies();

// 如果没有COOKIE，新建一个COOKIE
if (cookies == null) {

  out.println("cookies is null.
");

  cookie = new Cookie("new", "1");

  response.addCookie(cookie);

} else {

  out.println("cookies is not null.
");

  for (int i = 0; i < cookies.length; i++) {

   cookie = cookies[i];

   out.println("cookie" + i + " name: " + cookie.getName() + "
");
  }
}

HttpSession session = request.getSession();

if (session == null) {
  out.println("session is null.
");

} else {
  out.println("session is not null.
");
  out.println("session id: " + session.getId() + "
");
}

out.println("");
}

第一次访问这个SERVLET，页面显示

引用
cookies is null.
session is not null.
session id: 0D0AABB6F911362FEE87BEEB2953C33F

第二次访问，页面显示

引用
cookies is not null.
cookie0 name: new
cookie1 name: JSESSIONID
session is not null.
session id: 0D0AABB6F911362FEE87BEEB2953C33F

第二次访问时从客户端来了两个COOKIE，名为“new”的COOKIE是我创建的，名为“JSESSIONID”的COOKIE应该是服务器TOMCAT创建的，但这时，在本地硬盘里找不到这两个COOKIE的文件。

改一下SERVLET，在创建名为“new”的COOKIE时，加一句

Java代码
cookie.setMaxAge(1000);
cookie.setMaxAge(1000);
然后本地硬盘里就有“new”这个COOKIE了。

这下就有疑问了，在没有设置COOKIE存活期时，自己创建的SESSION不会存到本地硬盘，会不会TOMCAT创建的所谓的会话COOKIE也是没有设置存活期呢？

然后根据zddava的博客（http://zddava.javaeye.com/blog/311053），找到了TOMCAT里创建会话COOKIE的代码。
在
org.apache.catalina.connector.Request.java里，

Java代码
protected void configureSessionCookie(Cookie cookie) {
    cookie.setMaxAge(-1);
    String contextPath = null;
    if (!connector.getEmptySessionPath() && (getContext() != null)) {
        contextPath = getContext().getEncodedPath();
    }
    if ((contextPath != null) && (contextPath.length() > 0)) {
        cookie.setPath(contextPath);
    } else {
        cookie.setPath("/");
    }
    if (isSecure()) {
        cookie.setSecure(true);
    }
}
protected void configureSessionCookie(Cookie cookie) {
    cookie.setMaxAge(-1);
    String contextPath = null;
    if (!connector.getEmptySessionPath() && (getContext() != null)) {
        contextPath = getContext().getEncodedPath();
    }
    if ((contextPath != null) && (contextPath.length() > 0)) {
        cookie.setPath(contextPath);
    } else {
        cookie.setPath("/");
    }
    if (isSecure()) {
        cookie.setSecure(true);
    }
}
cookie.setMaxAge(-1);使COOKIE在浏览器被关闭时删除。而且这里的cookie和上面SERVLET里的cookie都是javax.servlet.http.Cookie。

由此得出结论:
可能最开始是我理解错了，COOKIE并没有会话COOKIE和持久COOKIE之分。我们本地创建的“持久COOKIE”和WEB容器创建的“会话COOKIE”都是一种COOKIE，就是javax.servlet.http.Cookie。只是WEB容器把存活期设置成了关闭浏览器时删除而已（TOMCAT）。
这个结论不正确。在服务器端设置过期时间后就是持久cookie了，所以有会话COOKIE和持久COOKIE之分。
************************************************************************
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
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
理解session机制
session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为 session id，如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个 session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个 session id将被在本次响应中返回给客户端保存。

保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于SEEESIONID，而。比如weblogic对于web应用程序生成的cookie，JSESSIONID= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是 JSESSIONID。

由于cookie可以被人为的禁止，必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面，附加方式也有两种，一种是作为URL路径的附加信息，表现形式为http://...../xxx;jsessionid= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
另一种是作为查询字符串附加在URL后面，表现形式为http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
这两种方式对于用户来说是没有区别的，只是服务器在解析的时候处理的方式不同，采用第一种方式也有利于把session id的信息和正常程序参数区分开来。
为了在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。

另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如下面的表单

在谈论session机制的时候，常常听到这样一种误解“只要关闭浏览器，session就消失了”。其实可以想象一下会员卡的例子，除非顾客主动对店家提出销卡，否则店家绝对不会轻易删除顾客的资料。对session来说也是一样的，除非程序通知服务器删除一个session，否则服务器会一直保留，程序一般都是在用户做log off的时候发个指令去删除session。然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所以会有这种错觉，是大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个 session id就消失了，再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session。

恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为seesion设置了一个失效时间，当距离客户端上一次使用session的时间超过这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session删除以节省存储空间。
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
由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了。

本文来自CSDN博客，http://blog.csdn.net/yuhua3272004/archive/2009/07/17/4357268.aspx

疯狂 2010-09-09 13:26 发表评论

探讨JavaClassLoader与Package机制

疯狂 — Wed, 01 Sep 2010 15:12:00 GMT

文章转自：http://blog.csdn.net/Senton/archive/2007/10/03/1810766.aspx

为了深入了解Java的ClassLoader机制，我们先来做以下实验：

package java.lang;
public class Test {
    public static void main(String[] args) {
        char[] c = "1234567890".toCharArray();
        String s = new String(0, 10, c);
    }
}

String类有一个Package权限的构造函数String(int offset, int length, char[] array)，按照默认的访问权限，由于Test属于java.lang包，因此理论上应该可以访问String的这个构造函数。编译通过！执行时结果如下：

Exception in thread "main" java.lang.SecurityException: Prohibited package name:
java.lang
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.access$100(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClassInternal(Unknown Source)

奇怪吧？要弄清为什么会有SecurityException，就必须搞清楚ClassLoader的机制。

Java的ClassLoader就是用来动态装载class的，ClassLoader对一个class只会装载一次，JVM使用的ClassLoader一共有4种：

启动类装载器，标准扩展类装载器，类路径装载器和网络类装载器。

这4种ClassLoader的优先级依次从高到低，使用所谓的“双亲委派模型”。确切地说，如果一个网络类装载器被请求装载一个java.lang.Integer，它会首先把请求发送给上一级的类路径装载器，如果返回已装载，则网络类装载器将不会装载这个java.lang.Integer，如果上一级的类路径装载器返回未装载，它才会装载java.lang.Integer。

类似的，类路径装载器收到请求后（无论是直接请求装载还是下一级的ClassLoader上传的请求），它也会先把请求发送到上一级的标准扩展类装载器，这样一层一层上传，于是启动类装载器优先级最高，如果它按照自己的方式找到了java.lang.Integer，则下面的ClassLoader 都不能再装载java.lang.Integer，尽管你自己写了一个java.lang.Integer，试图取代核心库的 java.lang.Integer是不可能的，因为自己写的这个类根本无法被下层的ClassLoader装载。

再说说Package权限。Java语言规定，在同一个包中的class，如果没有修饰符，默认为Package权限，包内的class都可以访问。但是这还不够准确。确切的说，只有由同一个ClassLoader装载的class才具有以上的Package权限。比如启动类装载器装载了java.lang.String，类路径装载器装载了我们自己写的java.lang.Test，它们不能互相访问对方具有Package权限的方法。这样就阻止了恶意代码访问核心类的Package权限方法。

疯狂 2010-09-01 23:12 发表评论

md5加盐验证用户密码的小例子

疯狂 — Tue, 09 Feb 2010 05:13:00 GMT

package com.test;

import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;
import java.security.MessageDigest;
import java.security.SecureRandom;
import java.util.Arrays;

//使用md5和盐验证安全登陆
public class Test_MD5 {

private static final String PWD_FILE = "c:\\pwd.txt";
/**
* @param args
*/
public static void main(String[] args) throws Exception{


  //用户创建密码，服务端杂凑并保存
  saveMessagePwdInFile("admin");
  ////验证用户输入
  checkUserPwd("admin1");


}
public static void saveMessagePwdInFile(String inputPwd)throws Exception{
  byte[] salt = new byte[8];
  SecureRandom random = new SecureRandom();
  random.nextBytes(salt);
  System.out.println("生成的盐："+Arrays.toString(salt));

  MessageDigest digest = MessageDigest.getInstance("MD5");//当然可以使用SHA（160位），MD5(128位)
  digest.update(salt);
  digest.update(inputPwd.getBytes("utf-8"));
  byte[] afterMd5 = digest.digest();
  System.out.println("杂凑值："+Arrays.toString(afterMd5));

  //盐和杂凑值写入文件
  FileOutputStream outputStream = new FileOutputStream(new File(PWD_FILE));
  FileChannel channel = outputStream.getChannel();
  channel.write(ByteBuffer.wrap(salt));
  channel.write(ByteBuffer.wrap(afterMd5));
  outputStream.flush();
  outputStream.close();
  System.out.println("保存信息完毕...");

}
public static void checkUserPwd(String pwd)throws Exception{
  ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
  FileInputStream fileInputStream = new FileInputStream(new File(PWD_FILE));
  FileChannel channel2 = fileInputStream.getChannel();
  ByteBuffer dst = ByteBuffer.allocate(1024);
  int l = -1;
  while((l=channel2.read(dst))!=-1){
   dst.flip();
   byteArrayOutputStream.write(dst.array(),0,l);
   dst.compact();
   dst.clear();
  }
  fileInputStream.close();
  byte[] pwdbyte = byteArrayOutputStream.toByteArray();
  byteArrayOutputStream.reset();

  byte[] salt2 = new byte[8];
  System.arraycopy(pwdbyte, 0, salt2, 0, 8);
  System.out.println("从文件获取盐："+Arrays.toString(salt2));
  byte[] pwdinfile = new byte[pwdbyte.length-8];
  System.arraycopy(pwdbyte, 8, pwdinfile, 0, pwdbyte.length-8);
  System.out.println("从文件获取杂凑值："+Arrays.toString(pwdinfile));
     byte[] toyz = getUserMd5Pwd(salt2,pwd);
     System.out.println(Arrays.equals(toyz, pwdinfile)==true?"登陆成功":"密码有误，登录失败...");
}

   public static byte[] getUserMd5Pwd(byte[] salt,String pwd) throws Exception{
    MessageDigest digest2 = MessageDigest.getInstance("MD5");
  digest2.update(salt);
     digest2.update(pwd.getBytes("utf-8"));
     byte[] toyz = digest2.digest();

     System.out.println("用户输入杂凑值："+Arrays.toString(toyz));
     return toyz;
   }
}

疯狂 2010-02-09 13:13 发表评论