@TOC
Cookie
Cookie简述:
- Cookie 翻译过来是饼干的意思。
- Cookie 是服务器通知客户端保存键值对的一种技术。
- 客户端有了 Cookie 后,每次请求都发送给服务器。
- 每个 Cookie 的大小不能超过 4kb
如何创建 Cookie:
服务器如何获取 Cookie:
Cookie 值的修改:
- 方案一: 1、先创建一个要修改的同名(指的就是 key)的 Cookie 对象 2、在构造器,同时赋于新的 Cookie 值。 3、调用 response.addCookie( Cookie );
- 方案二: 1、先查找到需要修改的 Cookie 对象 2、调用 setValue()方法赋于新的 Cookie 值。 3、调用 response.addCookie()通知客户端保存修改
Cookie 生命控制简述:
- Cookie 的生命控制指的是如何管理 Cookie 什么时候被销毁(删除)
- setMaxAge() : ①正数,表示在指定的秒数后过期 ②负数,表示浏览器一关,Cookie 就会被删除(默认值是-1)(即表示生命周期为当前会话) ③零,表示马上删除 Cookie
Cookie 有效路径 Path 的设置:
- Cookie 的 path 属性可以有效的过滤哪些 Cookie 可以发送给服务器。哪些不发。
- path 属性是通过请求的地址来进行有效的过滤。 ①CookieA -------------path=/工程路径 ②CookieB -------------path=/工程路径/abc
- 请求地址如下: ① http://ip:port/工程路径/a.html -------------CookieA 发送 CookieB 不发送 ② http://ip:port/工程路径/abc/a.html -------------CookieA 发送 CookieB 发送
Cookie的作用:
- 在浏览器中,经常涉及到数据交换,如:你登录一个页面。我们经常会设置自动登录选项。那么它们就是通过cookie来记住我们的信息的, cookie是由HTTP服务器设置的,保存在浏览器中。
- 但HTTP协议是一种无状态协议,在数据交换完毕后,服务端和客户端的链接就会关闭,每次交换数据都需要建立新的链接。
- 就像我们去超市买东西,没有积分卡的情况下,我们买完东西之后,超市没有我们任何的消费信息,但我们办了积分卡之后,超市就有了我们的消费信息。
- cookie就像是积分卡,可以保存积分,商品就是我们的信息,超市的系统就像服务器后台,HTTP协议就是交易的过程。
常用Cookie(JSESSIONID)介绍:
JSESSIONID是一个Cookie,Servlet容器(tomcat,jetty)用来记录用户session。- 什么时候种下JSESSIONID?
①创建会话时,即调用request.getSession()的时候,关于getSession就不说了。补充几点是,访问html是不会创建session的,JSP页面默认是会创建session的,可以在JSP页面里面关掉自动创建session.
②
jsessionid ==request.getSession().getId() - JSESSIONID工作原理:
- Jsessionid只是tomcat的对sessionid的叫法,其实就是sessionid;在其它的容器也许就不叫jsessionid了。
session对象当客户端首次访问时,创建一个新的session对象.并同时生成一个sessionId,并在此次响应中将sessionId以响应报文的方式些回客户端浏览器内存或以重写url方式送回客户端,来保持整个会话,只要sever端的这个session对象没有销毁,以后再调用request.getSession()时就直接根据客户端的sessionId来检索server端生成的session对象并返回,不会再次去新建,除非根据此sessionId没有检索到session对象。
Session
Session介绍:
- Session 就是一个接口(HttpSession)。
- Session 就是会话。它是用来维护一个客户端和服务器之间关联的一种技术。
- 每个客户端都有自己的一个 Session 会话。
- Session 会话中,我们经常用来保存用户登录之后的信息。
如何创建和获取 Session:
- 它们的 API 是一样的。
- request.getSession() : ①第一次调用是创建 Session 会话 ②之后调用都是获取前面创建好的 Session会话对象。
- isNew(): 判断到底是不是刚创建出来的(新的) true 表示刚创建 ,false 表示之前创建的。
- getId(): 得到 Session 的会话 id 值,每个会话都有一个身份证号,也就是 ID 值。而且这个 ID 是唯一的。
Session 域数据的存取:
- setAttribute()方法 存数据
- getAttribute()方法 取数据
Session 生命周期控制:
- public void setMaxInactiveInterval(int interval) :设置 Session的超时时间(以秒为单位),超过指定的时长,Session 就会被销毁。值为正数的时候,设定 Session 的超时时长。负数表示永不超时(极少使用)
- public int getMaxInactiveInterval():获取 Session 的超时时间
- public void invalidate(): 让当前 Session 会话马上超时无效
Session 默认的超时时间长为 30 分钟, 因为在 Tomcat 服务器的配置文件web.xml中默认有以下的配置,它就表示配置了当前 Tomcat 服务器下所有的 Session 超时配置默认时长为:30 分钟。
<session-config>
<session-timeout>30</session-timeout>
</session-config>
浏览器和 Session 之间关联的技术内幕:
-
Session 技术,底层其实是基于 Cookie 技术来实现的。
-
简而言之:Cookie是一种保存在浏览器的信息,Session是一种保存在服务器的信息。前者是用来针对用户的,后者是针对用户的一次会话的。Cookie可以单独使用,而Session必须借助Cookie才能使用。
-
举例:一个用户登录某个网站,当他下次登录时可以不用再输入表单信息,因为Cookie保存在了浏览器自动发送给服务器,服务器判断有Cookie(前提是在有效期内,一般是7天)放行。而该用户在一次会话中(浏览器未关闭)把想买的保存在了购物车,这些购物车信息是保存在服务器的,但是服务器怎么知道这些购物车信息是哪个用户的呢,这时会通过SessionID来判断,SessionID则是保存在发给浏览器的Cookie中。而这个Session一般是一个月的,也就代表保存SessionID的Cookie的生命周期是Session,也就是一个月。一个月后Cookie和Session同时销毁。
Session的作用:
- 实现购物车: ①Session版本(把购物车信息保存到Session域中) ②数据库版本(把购物车信息保存到数据库中) ③redis+数据库+Cookie(使用Cokkie+redis缓存和数据库)
- 实现验证法防止表单反复提交:
Session的底层基础:
- 同一个浏览器的两个页面是不一定是一个session的。
- 如果是在同一个浏览器内打开两个标签,那么这两个标签的页面是一个session。
- 但是用同一个浏览器打开两个不同的窗口页面的话,那么两个页面不是一个session。
- 因此一个session对应一个浏览器进程。
session过期怎么恢复:
- 众所周知,当用户登录网站后较长一段时间没有与服务器进行交互,将会导致服务器上的用户会话数据(即session)被销毁。此时,当用户再次操作网页时,如果服务器进行了session校验,那么浏览器将会提醒用户session超时。
- 那么,如何解决用户登录后较长时间未操作而导致的session失效的问题呢?
①导致这个问题的关键词有两个:
<1>一个是「长时间」,<2>一个是「未操作」。 - 如果用户未操作的「长时间」超过了服务器配置的session超时时间,并导致session失效,那么我们延长session的超时时间,让用户原来的「长时间」与超时时间相比,变得不「长」,不就可以解决了吗?
- 如果用户是长时间「未操作」导致session失效,那么我们想办法产生「操作」,让用户每隔一小段时间就「操作」一次,与服务器产生交互,那么session自然也不会失效。
- 一般情况下下,我们首先想到的是,通过改变服务器的配置,延长服务器的session超时时间。例如,在Tomcat服务器的web.xml文件中有如下节点内容: ①这里的30表示session的超时时间,单位为分钟,如果用户登录后在30分钟内没有与服务器交互,那么当前用户的session将失效。我们可以配置一个更大的数值(比如60),就可以延长session的超时时间,如果将该值改为0或负数的话,则表示session永不失效。
<session-config><session-timeout>30</session-timeout></session-config>
- 不过在实际的工作应用中,一味地上调session的超时时间设置并不怎么常见,大多数需要实现该功能的网站都将解决问题的焦点集中在第二条思路上。例如:一些在线网站均采用定时刷新页面的方法来防止session超时。 ①定时刷新页面,最常见的有两种实现方式:一种是通过JavaScript+HTMLDOM,另一种则是通过meta标签来实现。
一些网站的3天免登陆是如何做到的?
- 方式一:
首先想到的是使用cookie保存用户登录信息,设置有效期,在用户下次访问时免去登录环节,直接通过cookie获取用户信息。 - 方式二:
直接将session会话保存,用户下次访问时,继续使用这个session。相比之下session显得更加安全,但是,大家知道,session会随着浏览器的关闭而消失(确切的说,是在客户端消失,服务器端的session存活周期取决于相应配置),当用户下次启动浏览器,访问网站时,又会得到由网站自动分配的新的session。那么,问题来了: ①思路: 1、在用户登录成功时,创建session对象,保存用户信息 2、将此session的sessionid保存到cookie中 3、同时将sessionid于session对应关系存储到应用域中,以便后面可以根据sessionid来获取到session 4、在用户关闭浏览器,重新打开浏览器访问网站时,读取用户的cookie,得到sessionid 5、根据sessionid获取到第3步存储到应用域中的session对象 6、从session中读取用户信息
session与用户行为分析:
- 数据分析方法论:你真的懂 Session(会话)分析吗?
- 由于客户的访问次数是一个整型的变量,但session的属性类型中不能使用int,double,boolean等基本类型的变量,所以我们要用到这些基本类型的封装类型对象作为session对象中属性的值。 但像Integer是一种不可修改(Immutable)的数据结构:构建后就不能更改。这意味着每个请求都必须创建新的Integer对象,之后使用setAttribute来代替之前存在的老的属性的值。
同一用户不同终端登录限制解决方案:
- 大致思路就是做出userId与sessionId(一个终端对应一个session域,session Id唯一)的键值对,存于全局域application域。用于登录时判断用户是否在别的终端在线。
- 不过事情还没有结束。有存入就要有移除,不然关闭后就不能再登录了。当然,仅仅只做正常退出是的移除是不够的,现实中并不能保证所有用户都会乖乖的走你定下的退出流程。大多用户都是直接关闭浏览器了事,因此,这个事后处理还要由我们来做。
①
我们来设置一下session域的监听。当有session域销毁的时候,做出移除application中相应键值对的操作②当然,用户点击logout正常退出时记得移除application中相应的键值对。
关于多标签浏览器中session共享引发的问题:
- 当在标签a中使用用户A登录后,再打开标签b,进入登录界面使用用户B再次进行登录。那么标签a中的登录信息就变成了用户B的登录信息。这种情况显示不是用户希望得到的。两个标签页共用一个session。后一个把前一个的同名attribute域覆盖了,致使数据混乱。
- 解决办法: ①目标:实现多标签中登录多个用户而互不影响。 ②思路:将用户登录信息,比如用户编号、登录ip等封装到一个对象,然后以一个唯一值(比如登录时间)为key放入HashMap,再将HashMap放入session。