session

Cookie和会话状态的 工作 原理及Cookie欺骗 session是一种保存上下文信息的机制，它是针对每一个用户的，变量的值保存在服务器端，通过SessionID来区分不同的客户，session是以Cookie或URL重写为基础。默认使用Cookie来实现，系统会创造一个名为JSESSIONID的输出Cookie，或称为"Session Cookie"，以区别Persistent Cookies(通常所说的Cookie).Session Cookie是存储在浏览器中，并不是写在硬盘上的，但是把浏览器的Cookie禁止后，使用response对象的encodeURL或encodeRedirectURL方法编码URL，WEB服务器会采URL重写的方式传递Sessionid，用户就可以在地址栏看到jsessionid=A09JHGHKHU68624309UTY84932之类的字符串。 通常Session Cookie是不能跨窗口使用，当用户新开了一个浏览器进入相同的页面时，系统会赋予用户一个新的SessionID，这样信息共享的目的就达不到，此时可以把SessionID保存在Persistent Cookie中，然后再新的窗口中读出来，就可以得到上一个窗口的SessionID了，这样通过Session Cookie和Persistent Cookie的结合，实现了跨窗口的会话跟踪。

关于 tomcat 和 sessionCookieName 和 SESSION_PARAMETER_NAME 以及 disableURLRewriting 参数 关于 session 和 cookie 参考： http://www.blogjava.net/freeman1984/archive/2011/09/02/357833.html http://www.blogjava.net/freeman1984/archive/2010/09/09/331501.html http://www.blogjava.net/freeman1984/archive/2010/03/30/316901.html tomcat 服务端和客户端通过 sessionCookieName参数 （默认值： jsessionid ）的值来识别 session ，并在此 session 中共享数据。在浏览器首次请求服务的时候， tomcat 服务器会在响应头信息信息里面返回： 告诉浏览器保存cookie名为 JSESSIONID 的cookie，当然此时为会话cookie，此cookie是保存在浏览器当前会话中的。过期时间为当前会话结束时。(当然前提是浏览器要设置为接受第三方cookie) 在下次浏览器请求的时候会将此cookie值返回给服务器，当然cookie的名称同(

存在两种类型的cookie： Session cookies - these are temporary and are erased when you close your browser at the end of your surfing session. The next time you visit that particular site it will not recognise you and will treat you as a completely new visitor as there is nothing in your browser to let the site know that you have visited before 不设置过期时间，则表示这个cookie生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。 Persistent cookies - these remain on your hard drive until you erase them or they expire. How long a cookie remains on your browser depends on how long

Cookie和Session的作用： 都是用于存储一些关键数据。 Cookie和Session的存储位置： Cookie储存在客户端，Session储存在服务器 Cookie的产生和销毁以及原理： Cookie由服务器产生，通过HTTP协议发送给客户端。 在协议的响应头中的： Set-Cookie标注了这个cookie的信息 ： 下次如果有cookie带给服务器时，将会在 在协议的请求头中的：Cookie标注了这个cookie的信息： /* * 正值表示 cookie 将在经过该值表示的秒数后过期。注意，该值是 cookie 过期的最大 生存时间， 不是 * cookie的当前生存时间。 负值意味着 cookie 不会被持久存储，将在 Web 浏览器退出时删除。0 值会导致删除cookie */ cookie.setMaxAge(Integer.MAX_VALUE); 删除Cookie注意 ：由于在Http协议中请求发送Cookie的时候只是带有Cookie的名称和值， 但是一个Cookie的唯一标识是Cookie的名称+domain+path。 所以我们在 删除Cookie的时候为了能真正把原来的Cookie的MaxAge改成0的话，就必须要设置这个Cookie的domain和path， 设置的要与之前发送Cookie时一样。也就是说

1. 服务端只创建 cookie字符值： 客户端向服务端发送请求，建立连接。服务端创建 cookie字符值，作为响应头返回。 注意：如果客户端是浏览器，会自动存储这个 Set-Cookie 的值到 浏览器的session 中。如果是脚本，可以手动将该 cookie 保存起来（保存位置可能是session、硬盘或其他位置）。也可以将 cookie 通过响应头再次转发出去 。 2. 客户端（脚本）发送请求，获取 cookie，并维持一个 session中： 由于脚本的 session中，通过类似 session_id的东西 将 session 共享。当脚本发送的请求返回一个携带 set-cookie 的响应时，即将此 set-cookie 中的数据加载到 脚本的 session 中。 那么每次发送请求时，都可以携带此 cookie。（注意：session 是内存的一个区域，并不表示 内存就是 session） 3. 另一种解决方案。客户端（脚本）发送请求，获取 cookie，手动存储到内存、本地硬盘或数据库中： 脚本获取 携带 set-cookie 的响应， 手动将 cookie保存到内存、硬盘或数据库中。这样每次发送请求时，需手动获取 cookie并放置该 cookie 到此请求的 request header 中。 PS：浏览器其实也是维持一个 “智能” session，这个

会话（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 由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就 给客户端们颁发一个通行证吧

JSTL优势：在于EL和标准动作无法达到目的，又不使用脚本代码。（ JSTL 1.1不是JSP2.0规范的一部分，TOMCAT高版本已经自带了JSTL的JAR包 ） 使用JSTL需要使用指令，引入JSTL <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%> 8.3 核心标签库 JSTL核心标签库包含了一组用于实现WEB应用中的通用操作的标签，JSP规范为核心标签库建议的前缀名为c。 8.3.1 <c:out>标签 <c:out> 标签用于输出一段文本内容到pageContext对象当前保存的“out”对象中，在通常情况下，pageContext对象当前保存的“out”对象的数据是输出到客户端浏览器，所以，<c:out> 标签通常用于输出一段文本内容到客户端浏览器。如果<c:out> 标签输出的文本内容中包含了需要进行转义的HTML特殊字符，例如，<、>、'、"、&等，<c:out> 标签默认对它们按表8.2进行HTML编码转换后再进行输出，这样就可以在浏览器中显示出这些字符。 表8.2 特殊字符转换 <c:out>标签标签有两种语法格式： 语法1 ，没有标签体的情况： <c:out value=" value " [escapeXml="{true|false}"] [default="

http://www.justwinit.cn/post/2815/ 1.打开secureCRT，按alt+b，可以调出快速启动栏。 2.按ctrl，可以同时选中多个session，再点击连接，可快速连接。 3.打开的第一个标签记为数字1，第二个记为2，依次类推，可用alt+1、alt+2……这种方式在不同标签之间切换。 4.按钮栏，在查看->按钮栏，会在下面列出一排按钮，可以对其进行逐一的编辑，包含不同的动作，视频里演示的是一次性完成路由器的初始化配置，编辑一个按钮，选择动作是send string，输入代码是“en\r conf t\r no ip domain lo\r line con0\r logg s\r exec-t 00\r exit\r hostname R”其中\r代表回车，都是些基本的配置。 5.交互窗口，在查看->交互窗口，会在下面显示交互的窗口，在空白处点击右键，选择将交互发送至所有标签，这样在交互窗口输入的命令，会同时在多个标签中同时执行，有时候为了验证配置情况，需要各自show run，有了这种方法，就可以一次性搞定所有的输入了。 6.脚本录制，脚本->开始录制脚本，在配置之前打开脚本录制，结束后停止脚本录制，保存成一个脚本文件，关闭软件后，重新打开执行之前的脚本，相当于由机器自动完成了之前的所有配置

一、现象： 在WebLogic中，有两个不同域A（端口：9000）和B（端口：8000），应用CA在域A中，应用CB在域B中，进行如下操作： 1、先登录应用CA，再登录应用CB，然后，切换回应用CA，发现应用CA的Session丢失； 2、应用CA中有指向应用CB的链接，登录应用CA，点击指向应用CB的链接，应用CA的Session丢失； 二、原因： 因Cookie冲突导致Session丢失。 Cookie的覆盖机制： 如果一个新的cookie与一个已存在的cookie的NAME、Domain和Path属性值均相同，则旧的cookie会被丢弃。（参考： http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies ） WebLogic的Cookie相关配置： 属性名 默认值 值 cookie-name JSESSIONID 如未设置，默认为“JSESSIONID” cookie-path NULL 如未设置，默认为“/” cookie-domain NULL 如未设置，默认为发放cookie的服务器的域 　　由于没有在Weblogic.xml配置文件中对cookie的相关属性值进行配置，因此应用CA和应用CB的cookie的Name、 Domain和Path属性值均为默认值

MyBatis 实践 标签： Java与存储 MyBatis简介 MyBatis 前身是 iBatis ,是一个基于Java的 数据持久层/对象关系映射(ORM)框架 . MyBatis是对JDBC的封装,使开发人员只需关注SQL本身,而不需花费过多的精力去处理如 注册驱动 、 设置参数 、 创建 Connection / Statement 、 解析结果集 等JDBC过程性代码.MyBatis基于XML/注解的方式配置 Statement ,执行SQL,并将执行结果映射成Java对象, 大大降低了数据库开发的难度. MyBatis is a first class persistence framework with support for custom SQL, stored procedures and advanced mappings. MyBatis eliminates almost all of the JDBC code and manual setting of parameters and retrieval of results. MyBatis can use simple XML or Annotations for configuration and map primitives, Map interfaces and Java POJOs