会话（Session）

会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。

Cookie通过在客户端记录信息确定用户身份Session通过在服务器端记录信息确定用户身份。

http是一个无状态协议

什么是无状态呢？就是说这一次请求和上一次请求是没有任何关系的，互不认识的，没有关联的。这种无状态的的好处是快速。坏处是假如我们想要把www.zhihu.com/login.html和www.zhihu.com/index.html关联起来，必须使用某些手段和工具

cookie

背景

Cookie意为“甜饼”，是由W3C组织提出，最早由Netscape社区发展的一种机制。目前Cookie已经成为标准，所有的主流浏览器如IE、Netscape、Firefox、Opera等都支持Cookie。

定义

cookie是服务器传给客户端的体积很小的纯文本文件。客户端请求服务器，如果服务器需要记录该用户状态，就向客户端浏览器发一个cookie。客户端浏览器会把cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该cookie一同提交给服务器。服务器检查该cookie，以此来辨认用户状态

Cookie的工作原理

由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。

cookie机制

cookie的生成（java代码举例）：

Cookie cookie = new Cookie(“key”,”value”)； cookie.setMaxAge(60)； //设置cookie的生存期60秒 cookie.setPath(“/test”)；//设置cookie的路径

cookie会附在请求资源的HTTP请求头上发送给服务器，服务器通过相应方法获得该cookie。

cookie属性

cookie的主要属性包括：名字，值，过期时间，路径和域：

路径与域一起构成cookie的作用范围。过期时间：对于会话cookie，如果不设置过期时间，表示这个cookie的生命期为浏览器的会话期间，关闭浏览器窗口，cookie就消失了，会话cookie一般保存在内存里。对于持久cookie，设置了过期时间，浏览器会把cookie保存在硬盘上，存储在硬盘上的cookie会在不同的浏览器进程间共享。名字：就是给cookie起一个名字。值：cookie中记录的信息内容。

Cookie的不可跨域名性

很多网站都会使用Cookie。例如，Google会向客户端颁发Cookie，Baidu也会向客户端颁发Cookie。那浏览器访问Google会不会也携带上Baidu颁发的Cookie呢？或者Google能不能修改Baidu颁发的Cookie呢？

答案是否定的。Cookie具有不可跨域名性。根据Cookie规范，浏览器访问Google只会携带Google的Cookie，而不会携带Baidu的Cookie。Google也只能操作Google的Cookie，而不能操作Baidu的Cookie。

Cookie在客户端是由浏览器来管理的。浏览器能够保证Google只会操作Google的Cookie而不会操作Baidu的Cookie，从而保证用户的隐私安全。浏览器判断一个网站是否能操作另一个网站Cookie的依据是域名。Google与Baidu的域名不一样，因此Google不能操作Baidu的Cookie。

需要注意的是，虽然网站images.google.com与网站www.google.com同属于Google，但是域名不一样，二者同样不能互相操作彼此的Cookie。

注意：用户登录网站www.google.com之后会发现访问images.google.com时登录信息仍然有效，而普通的Cookie是做不到的。这是因为Google做了特殊处理。本章后面也会对Cookie做类似的处理。

应用场景

判断注册用户是否已经登录网站：用户可能会得到提示，是否在下一次进入此网站时保留用户信息以便简化登录流程。根据用户的爱好定制内容：网站创建包含用户浏览内容的cookies，在用户下次访问时，网站根据用户的情况对显示的内容进行调整，将用户感兴趣的内容放在前列。实现永久登录：如果用户是在自己家的电脑上上网，登录时就可以记住他的登录信息，下次访问时不需要再次登录，直接访问即可。实现自动登录：当用户注册网站后，就会收到一个惟一用户ID的cookie。用户再次连接时，这个用户ID会自动返回，服务器对它进行检查，确定它是否是注册用户且选择了自动登录，从而使用户无需给出明确的用户名和密码，就可以访问服务器上的资源。使用cookie记录各个用户的访问计数：获取cookie数组中专门用于统计用户访问次数的cookie的值，将值加1并将最新cookie输出。使用cookie记住用户名与用户密码。用户勾选了“自动登录”，就把用户名和密码的信息放到cookie中。同时可设置有效期。用cookie实现新手大礼包等弹窗功能。同理，将新手大礼包弹窗逻辑写入到cookie中，并设置相应的有效期。比如在有效期内只弹出一次该弹窗，超过有效期登录后再次弹出弹窗。

案例 sso单点登录

编辑UserController ticket存储在redis中.当key

@RequestMapping("/doLogin") @ResponseBody public SysResult doLogin(User user, HttpServletResponse response){ String ticket = userService.doLogin(user); if(StringUtils.isEmpty(ticket)){ //说明用户名或者密码错误 return SysResult.fail(); }else{ //1.创建Cookie Cookie cookie = new Cookie("JT_TICKET",ticket); cookie.setMaxAge(7*24*60*60); //设定cookie存活有效期 cookie.setPath("/"); //设定cookie有效范围 cookie.setDomain("jt.com"); //设定cookie共享的域名 是实现单点登录必备要素 response.addCookie(cookie); return SysResult.success(); //表示用户登录成功!! } }

编辑Cookie工具API

CookieUtil

新增cookie根据name查询value的值删除cookie package com.jt.util; import javax.servlet.http.Cookie; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; public class CookieUtil { //1.新增cookie public static void addCookie(HttpServletResponse response,String cookieName, String cookieValue, int seconds, String domain){ Cookie cookie = new Cookie(cookieName,cookieValue); cookie.setMaxAge(seconds); cookie.setDomain(domain); cookie.setPath("/"); response.addCookie(cookie); } //2.根据name查询value的值 public static String getCookieValue(HttpServletRequest request,String cookieName){ Cookie[] cookies = request.getCookies(); if(cookies !=null && cookies.length >0){ for (Cookie cookie : cookies){ if(cookieName.equals(cookie.getName())){ return cookie.getValue(); } } } return null; } //3.删除cookie public static void deleteCookie(HttpServletResponse response,String cookieName,String domain){ addCookie(response,cookieName,"",0, domain); } }

session

定义

session是另一种记录客户状态的机制，不同的是cookie保存在客户端浏览器中，而session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上，这就是session。客户端浏览器再次访问时只需要从该session中查找该客户的状态就可以了。session相当于程序在服务器上建立的一份用户的档案，用户来访的时候只需要查询用户档案表就可以了。

简而言之, session 有用户信息档案表, 里面包含了用户的认证信息和登录状态等信息. 而 cookie 就是用户通行证

session的生命周期与有效期

为了获得更高的存取速度，服务器一般把session放在内存里。每个用户都会有一个独立的session。如果session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。session的使用虽然比cookie方便，但是过多的session存储在服务器内存中，会对服务器造成压力。因此，session里的信息应该尽量精简。

session在用户第一次访问服务器的时候自动创建。session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该session。

由于有越来越多的用户访问服务器，因此session也会越来越多。为防止内存溢出，服务器会把长时间内没有活跃的session从内存中删除。这个时间就是session的超时时间。如果超过了超时时间没访问过服务器，session就自动失效了。

session与cookie关联

虽然session保存在服务器，但是它的正常运行仍然需要客户端浏览器的支持。这是因为session需要使用cookie作为识别标志。HTTP协议是无状态的，session不能依据HTTP连接来判断是否为同一客户，因此服务器向客户端浏览器发送一个名为SESSIONID的cookie，它的值为该Session的id。Session依据该cookie来识别是否为同一用户。

对于不支持cookie的手机浏览器，有另一种解决方案：URL地址重写。URL地址重写的原理是将该用户session的id信息重写到URL地址中，服务器能够解析重写后的URL获取session的id。这样即使客户端不支持cookie，也可以使用session来记录用户状态。

应用场景

通过session累计用户数据。例如，一个未登录用户访问了京东网站，这个时候京东对其下发了一个cookie，假设cookie的名字叫做abc，那这条记录就是 abc＝001，同时京东的后台也生成了一个 session id， 它的值也为 001， 001 这个客户在 2 点、 3 点、 4 点分别添加了三件商品到购物车，这样后台也记录了 session id为 001的用户的购物车里面已经有三件商品，并且只要每次客户端 cookie 带上来的值里面包含session id，后台都能够展示相应的数据，如果这个时候，在浏览器里面清空 cookie，cookie 数据消失之后，后台和客户端无法建立对应关系，购物车的数据就会失效了。通过session实现单点登录。一个用户帐号成功登录后，在该次session还未失效之前，不能在其他机器上登录同一个帐号。登录后将用户信息保存到session中，如果此时在另外一台机器上一个相同的帐号请求登录，通过遍历（遍历的意思就是将所有session都查看一遍）Web服务器中所有session并判断其中是否包含同样的用户信息，如果有，在另一台机器上是不能登录该帐号的。

token 令牌

定义

token 也称作令牌，由uid+time+sign[+固定参数] token 的认证方式类似于临时的证书签名, 并且是一种服务端无状态的认证方式, 非常适合于 REST API 的场景. 所谓无状态就是服务端并不会保存身份认证相关的数据。

组成

uid: 用户唯一身份标识time: 当前时间的时间戳sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串，以防止第三方恶意拼接固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查

存放

token在客户端一般存放于localStorage，cookie，或sessionStorage中。在服务器一般存于数据库中

token认证流程

token 的认证流程与cookie很相似

用户登录，成功后服务器返回Token给客户端。客户端收到数据后保存在客户端客户端再次访问服务器，将token放入headers中服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码

token可以抵抗csrf，cookie+session不行

假如用户正在登陆银行网页，同时登陆了攻击者的网页，并且银行网页未对csrf攻击进行防护。攻击者就可以在网页放一个表单，该表单提交src为http://www.bank.com/api/transfer，body为count=1000&to=Tom。倘若是session+cookie，用户打开网页的时候就已经转给Tom1000元了.因为form 发起的 POST 请求并不受到浏览器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域发送 POST 请求，形成 CSRF 攻击。在post请求的瞬间，cookie会被浏览器自动添加到请求头中。但token不同，token是开发者为了防范csrf而特别设计的令牌，浏览器不会自动添加到headers里，攻击者也无法访问用户的token，所以提交的表单无法通过服务器过滤，也就无法形成攻击。

分布式情况下的session和token

我们已经知道session时有状态的，一般存于服务器内存或硬盘中，当服务器采用分布式或集群时，session就会面对负载均衡问题。

负载均衡多服务器的情况，不好确认当前用户是否登录，因为多服务器不共享session。这个问题也可以将session存在一个服务器中来解决，但是就不能完全达到负载均衡的效果。当今的几种解决session负载均衡的方法。

而token是无状态的，token字符串里就保存了所有的用户信息

客户端登陆传递信息给服务端，服务端收到后把用户信息加密（token）传给客户端，客户端将token存放于localStroage等容器中。客户端每次访问都传递token，服务端解密token，就知道这个用户是谁了。通过cpu加解密，服务端就不需要存储session占用存储空间，就很好的解决负载均衡多服务器的问题了。这个方法叫做JWT(Json Web Token)

JWT 简介

概念

JWT是一种用于双方之间传递安全信息的简洁的、URL安全的表述性声明规范。JWT作为一个开放的标准（RFC 7519），定义了一种简洁的，自包含的方法用于通信双方之间以Json对象的形式安全的传递信息。因为数字签名的存在，这些信息是可信的，JWT可以使用HMAC算法或者是RSA的公私秘钥对进行签名。

简洁(Compact): 可以通过URL，POST参数或者在HTTP header发送，因为数据量小，传输速度也很快自包含(Self-contained)：负载中包含了所有用户所需要的信息，避免了多次查询数据库

JWT的结构

WT包含了使用.分隔的三部分：

Header 头部Payload 负载Signature 签名

其结构看起来是这样的 xxxxx.yyyyy.zzzzz

Header

在header中通常包含了两部分：

token类型和采用的加密算法

{ “alg”: “HS256”, “typ”: “JWT” }

JWT的主要应用场景

身份认证 在这种场景下，一旦用户完成了登陆，在接下来的每个请求中包含JWT，可以用来验证用户身份以及对路由，服务和资源的访问权限进行验证。由于它的开销非常小，可以轻松的在不同域名的系统中传递，所有目前在**单点登录（SSO）**中比较广泛的使用了该技术。信息交换 在通信的双方之间使用JWT对数据进行编码是一种非常安全的方式，由于它的信息是经过签名的，可以确保发送者发送的信息是没有经过伪造的。

总结

session存储于服务器，可以理解为一个状态列表，拥有一个唯一识别符号sessionId，通常存放于cookie中。服务器收到cookie后解析出sessionId，再去session列表中查找，才能找到相应session。依赖cookiecookie类似一个令牌，装有sessionId，存储在客户端，浏览器通常会自动添加。token也类似一个令牌，无状态，用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户。需要开发者手动添加。jwt只是一个跨域认证的方案