一文彻底弄懂cookie、session、token

本文主要是介绍一文彻底弄懂cookie、session、token，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

前言

作为一个JAVA开发，之前有好几次出去面试，面试官都问我，JAVAWeb掌握的怎么样，我当时就不知道怎么回答，Web，日常开发中用的是什么？今天我们来说说JAVAWeb最应该掌握的三个内容。

发展历程

1、很久很久以前，Web 基本上就是文档的浏览而已，既然是浏览，作为服务器，不需要记录谁在某一段时间里都浏览了什么文档，每次请求都是一个新的HTTP协议，就是请求加响应，尤其是我不用记住是谁刚刚发了HTTP请求，每个请求对我来说都是全新的。

2、但是随着交互式Web应用的兴起，像在线购物网站，需要登录的网站等等，马上就面临一个问题，那就是要管理会话，必须记住哪些人登录系统，哪些人往自己的购物车中放商品，也就是说我必须把每个人区分开，这就是一个不小的挑战，因为HTTP请求是无状态的，所以想出的办法就是给大家发一个会话标识(session id), 说白了就是一个随机的字串，每个人收到的都不一样，每次大家向我发起HTTP请求的时候，把这个字符串给一并捎过来，这样我就能区分开谁是谁了。

3、这样大家很嗨皮了，可是服务器就不嗨皮了，每个人只需要保存自己的session id，而服务器要保存所有人的session id ！如果访问服务器多了，就得由成千上万，甚至几十万个。

这对服务器说是一个巨大的开销，严重的限制了服务器扩展能力，比如说我用两个机器组成了一个集群，小F通过机器A登录了系统，那session id会保存在机器A上，假设小F的下一次请求被转发到机器B怎么办？机器B可没有小F的 session id啊。

有时候会采用一点小伎俩： session sticky ，就是让小F的请求一直粘连在机器A上，但是这也不管用，要是机器A挂掉了，还得转到机器B去。

那只好做session 的复制了，把session id 在两个机器之间搬来搬去，快累死了。

后来有个叫Memcached的支了招：把session id 集中存储到一个地方，所有的机器都来访问这个地方的数据，这样一来，就不用复制了，但是增加了单点失败的可能性，要是那个负责session 的机器挂了，所有人都得重新登录一遍，估计得被人骂死。

也尝试把这个单点的机器也搞出集群，增加可靠性，但不管如何，这小小的session 对我来说是一个沉重的负担

4 于是有人就一直在思考，我为什么要保存这可恶的session呢，只让每个客户端去保存该多好？

可是如果不保存这些session id , 怎么验证客户端发给我的session id 的确是我生成的呢？如果不去验证，我们都不知道他们是不是合法登录的用户，那些不怀好意的家伙们就可以伪造session id , 为所欲为了。

嗯，对了，关键点就是验证！

比如说，小F已经登录了系统，我给他发一个令牌(token)，里边包含了小F的 user id，下一次小F 再次通过Http 请求访问我的时候，把这个token 通过Http header 带过来不就可以了。

不过这和session id没有本质区别啊，任何人都可以可以伪造，所以我得想点儿办法，让别人伪造不了。

那就对数据做一个签名吧，比如说我用HMAC-SHA256 算法，加上一个只有我才知道的密钥，对数据做一个签名，把这个签名和数据一起作为token ，由于密钥别人不知道，就无法伪造token了。

这个token 我不保存，当小F把这个token 给我发过来的时候，我再用同样的HMAC-SHA256 算法和同样的密钥，对数据再计算一次签名，和token 中的签名做个比较，如果相同，我就知道小F已经登录过了，并且可以直接取到小F的user id , 如果不相同，数据部分肯定被人篡改过，我就告诉发送者：对不起，没有认证。

Token 中的数据是明文保存的（虽然我会用Base64做下编码，但那不是加密），还是可以被别人看到的，所以我不能在其中保存像密码这样的敏感信息。

当然，如果一个人的token 被别人偷走了，那我也没办法，我也会认为小偷就是合法用户，这其实和一个人的session id 被别人偷走是一样的。

这样一来，我就不保存session id 了，我只是生成token , 然后验证token ，我用我的CPU计算时间获取了我的session 存储空间！

解除了session id这个负担，可以说是无事一身轻，我的机器集群现在可以轻松地做水平扩展，用户访问量增大，直接加机器就行。这种无状态的感觉实在是太好了！

Cookie

1.什么是Cookie

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

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

Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。Cookie存储的数据量有限，且都是保存在客户端浏览器中。不同的浏览器有不同的存储大小，但一般不超过4KB。因此使用Cookie实际上只能存储一小段的文本信息（key-value格式）。

2.Cookie的机制

当用户第一次访问并登陆一个网站的时候，cookie的设置以及发送会经历以下4个步骤：

客户端发送一个请求到服务器；
服务器发送一个HttpResponse响应到客户端，其中包含Set-Cookie的头部；
客户端保存cookie，之后向服务器发送请求时，HttpRequest请求中会包含一个Cookie的头部；
服务器返回响应数据。

为了探究这个过程，写了代码进行测试，如下：

我在doGet方法中，new了一个Cookie对象并将其加入到了HttpResponse对象中

@RestController 
public class TestController {     
    @GetMapping(value = "/doGet")
   public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
      Cookie cookie = new Cookie("jiangwang",System.currentTimeMillis()+""); 
      // 设置生命周期为MAX_VALUE
      cookie.setMaxAge(Integer.MAX_VALUE);
      resp.addCookie(cookie);
   }
}

浏览器输入地址进行访问，结果如图所示：

可见Response Headers中包含Set-Cookie头部，而Request Headers中包含了Cookie头部。name和value正是上述设置的。

.Cookie的属性

Expires

该属性用来设置Cookie的有效期。Cookie中的maxAge用来表示该属性，单位为秒。Cookie中通过getMaxAge()和setMaxAge(int maxAge)来读写该属性。maxAge有3种值，分别为正数，负数和0。

如果maxAge属性为正数，则表示该Cookie会在maxAge秒之后自动失效。浏览器会将maxAge为正数的Cookie持久化，即写到对应的Cookie文件中（每个浏览器存储的位置不一致）。无论客户关闭了浏览器还是电脑，只要还在maxAge秒之前，登录网站时该Cookie仍然有效。下面代码中的Cookie信息将永远有效。

当maxAge属性为负数，则表示该Cookie只是一个临时Cookie，不会被持久化，仅在本浏览器窗口或者本窗口打开的子窗口中有效，关闭浏览器后该Cookie立即失效。

当maxAge为0时，表示立即删除Cookie。

修改或者删除Cookie

HttpServletResponse提供的Cookie操作只有一个addCookie(Cookie cookie)，所以想要修改Cookie只能使用一个同名的Cookie来覆盖原先的Cookie。如果要删除某个Cookie，则只需要新建一个同名的Cookie，并将maxAge设置为0，并覆盖原来的Cookie即可。

新建的Cookie，除了value、maxAge之外的属性，比如name、path、domain都必须与原来的一致才能达到修改或者删除的效果。否则，浏览器将视为两个不同的Cookie不予覆盖。

Cookie的域名

Cookie是不可以跨域名的，隐私安全机制禁止网站非法获取其他网站的Cookie。

正常情况下，同一个一级域名下的两个二级域名也不能交互使用Cookie，比如a1.jiangwang.com和a2.jiangwang.com，因为二者的域名不完全相同。如果想要jiangwnag.com名下的二级域名都可以使用该Cookie，需要设置Cookie的domain参数为.jiangwang.com，这样使用a1.jiangwang.com和a2.jiangwang.com就能访问同一个cookie

一级域名又称为顶级域名，一般由字符串+后缀组成。熟悉的一级域名有baidu.com，qq.com。com，cn，net等均是常见的后缀。二级域名是在一级域名下衍生的，比如有个一级域名为abc.com，则blog.abc.com和www.abc.com均是其衍生出来的二级域名。

Cookie的路径

path属性决定允许访问Cookie的路径。比如，设置为"/"表示允许所有路径都可以使用Cookie

4.应用

Cookies最典型的应用是判定注册用户是否已经登录网站，用户可能会得到提示，是否在下一次进入此网站时保留用户信息以便简化登录手续，这些都是Cookies的功用。另一个重要应用场合是“购物车”之类处理。用户可能会在一段时间内在同一家网站的不同页面中选择不同的商品，这些信息都会写入Cookies，以便在最后付款时提取信息。

Session

1.什么是Session

在WEB开发中，服务器可以为每个用户浏览器创建一个会话对象（session对象），注意：一个浏览器独占一个session对象(默认情况下)。因此，在需要保存用户数据时，服务器程序可以把用户数据写到用户浏览器独占的session中，当用户使用浏览器访问其它程序时，其它程序可以从用户的session中取出该用户的数据，为用户服务。

2.Session实现原理

服务器创建session出来后，会把session的id号，以cookie的形式回写给客户机，这样，只要客户机的浏览器不关，再去访问服务器时，都会带着session的id号去，服务器发现客户机浏览器带session id过来了，就会使用内存中与之对应的session为之服务。可以用如下的代码证明：

第一次访问时，服务器会创建一个新的sesion，并且把session的Id以cookie的形式发送给客户端浏览器，如下图所示：

再次请求服务器，此时就可以看到浏览器再请求服务器时，会把存储到cookie中的session的Id一起传递到服务器端了，如下图所示：

3.session创建和销毁

在程序中第一次调用request.getSession()方法时就会创建一个新的Session，可以用isNew()方法来判断Session是不是新创建的

session对象默认30分钟没有使用，则服务器会自动销毁session，也可以手工配置session的失效时间，例如：

session.setMaxInactiveInterval(10*60);//10分钟后session失效

当需要在程序中手动设置Session失效时，可以手工调用session.invalidate方法，摧毁session。

面试题：浏览器关闭，session就销毁了？不对.

Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器，Session就自动失效了。

Token

1.什么是Token

token的意思是“令牌”，是服务端生成的一串字符串，作为客户端进行请求的一个标识。

当用户第一次登录后，服务器生成一个token并将此token返回给客户端，以后客户端只需带上这个token前来请求数据即可，无需再次带上用户名和密码。

简单token的组成；uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign（签名，token的前几位以哈希算法压缩成的一定长度的十六进制字符串。为防止token泄露）。

2.Token的原理

用户通过用户名和密码发送请求
程序校验
程序返回一个Token给客户端
客户端存储Token，并且每次发送请求携带Token
服务端验证Token，并返回数据

3.Token的使用

附上一段在项目中使用Token的实例：

public class JWTToken implements AuthenticationToken {

// 密钥

private String token;

public JWTToken(String token) {

this.token = token;

}

@Override

public Object getPrincipal() {

return token;

}

@Override

public Object getCredentials() {

return token;

}

@Component

public class JWTFilter extends BasicHttpAuthenticationFilter {

private static final Logger log = LoggerFactory.getLogger(JWTFilter.class);

/**

* 认证之前执行该方法

* @param request

* @param response

* @param mappedValue

* @return

@Override

protected boolean isAccessAllowed(ServletRequest request, ServletResponse response, Object mappedValue) {

Subject subject = SecurityUtils.getSubject();

return null != subject && subject.isAuthenticated();

}

/**

* 认证未通过执行该方法

* @param request

* @param response

* @return

@Override

protected boolean onAccessDenied(ServletRequest request, ServletResponse response){

//完成token登入

//1.检查请求头中是否含有token

HttpServletRequest httpServletRequest= (HttpServletRequest) request;

String token = httpServletRequest.getHeader("Authorization");

//2. 如果客户端没有携带token，拦下请求

if(null==token||"".equals(token)){

responseTokenError(response,"Token无效，您无权访问该接口");

return false;

}

//3. 如果有，进行token验证

JWTToken jwtToken = new JWTToken(token);

try {

SecurityUtils.getSubject().login(jwtToken);

} catch (AuthenticationException e) {

log.error(e.getMessage());

responseTokenError(response,e.getMessage());

return false;

}

return true;

}

/**

* 对跨域提供支持

@Override

protected boolean preHandle(ServletRequest request, ServletResponse response) throws Exception {

HttpServletRequest httpServletRequest = (HttpServletRequest) request;

HttpServletResponse httpServletResponse = (HttpServletResponse) response;

httpServletResponse.setHeader("Access-control-Allow-Origin", httpServletRequest.getHeader("Origin"));

httpServletResponse.setHeader("Access-Control-Allow-Methods", "GET,POST,OPTIONS,PUT,DELETE");

httpServletResponse.setHeader("Access-Control-Allow-Headers", httpServletRequest.getHeader("Access-Control-Request-Headers"));

// 跨域时会首先发送一个option请求，这里我们给option请求直接返回正常状态

if (httpServletRequest.getMethod().equals(RequestMethod.OPTIONS.name())) {

httpServletResponse.setStatus(HttpStatus.OK.value());

return false;

}

return super.preHandle(request, response);

}

/**

* 无需转发，直接返回Response信息 Token认证错误

private void responseTokenError(ServletResponse response, String msg) {

HttpServletResponse httpServletResponse = WebUtils.toHttp(response);

httpServletResponse.setStatus(HttpStatus.OK.value());

httpServletResponse.setCharacterEncoding("UTF-8");

httpServletResponse.setContentType("application/json; charset=utf-8");

try (PrintWriter out = httpServletResponse.getWriter()) {

String data = new Gson().toJson(new ResponseBean(4001, msg, null));

out.append(data);

} catch (IOException e) {

e.printStackTrace();

log.error(e.getMessage());

}

@Service

public class UserRealm extends AuthorizingRealm {

@Autowired

private UserService userService;

/**

* 大坑！，必须重写此方法，不然Shiro会报错

@Override

public boolean supports(AuthenticationToken token) {

return token instanceof JWTToken;

}

/**

* 只有当需要检测用户权限的时候才会调用此方法，例如checkRole,checkPermission之类的

@Override

protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) {

SimpleAuthorizationInfo authorizationInfo = new SimpleAuthorizationInfo();

ActiveUser activeUser = (ActiveUser) SecurityUtils.getSubject().getPrincipal();

if(activeUser.getUser().getType()==0){

authorizationInfo.addStringPermission("*:*");

}else {

List<String> permissions = new ArrayList<>(activeUser.getPermissions());

List<Role> roleList = activeUser.getRoles();

//授权角色

if (!CollectionUtils.isEmpty(roleList)) {

for (Role role : roleList) {

authorizationInfo.addRole(role.getRoleName());

}

//授权权限

if (!CollectionUtils.isEmpty(permissions)) {

for (String permission : permissions) {

if (permission != null && !"".equals(permission)) {

authorizationInfo.addStringPermission(permission);

}

return authorizationInfo;

}

/**

* 默认使用此方法进行用户名正确与否验证，错误抛出异常即可。

@Override

protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken auth) throws AuthenticationException {

String token = (String) auth.getCredentials();

// 解密获得username，用于和数据库进行对比

String username = JWTUtils.getUsername(token);

if (username == null) {

throw new AuthenticationException(" token错误，请重新登入！");

}

User userBean = userService.findUserByName(username);

if (userBean == null) {

throw new AccountException("账号不存在!");

}

if(JWTUtils.isExpire(token)){

throw new AuthenticationException(" token过期，请重新登入！");

}

if (! JWTUtils.verify(token, username, userBean.getPassword())) {

throw new CredentialsException("密码错误!");

}

if(userBean.getStatus()==0){

throw new LockedAccountException("账号已被锁定!");

}

//如果验证通过，获取用户的角色

List<Role> roles= userService.findRolesById(userBean.getId());

//查询用户的所有菜单(包括了菜单和按钮)

List<Menu> menus=userService.findMenuByRoles(roles);

Set<String> urls=new HashSet<>();

Set<String> perms=new HashSet<>();

if(!CollectionUtils.isEmpty(menus)){

for (Menu menu : menus) {

String url = menu.getUrl();

String per = menu.getPerms();

if(menu.getType()==0&& !StringUtils.isEmpty(url)){

urls.add(menu.getUrl());

}

if(menu.getType()==1&&!StringUtils.isEmpty(per)){

perms.add(menu.getPerms());

}

//过滤出url,和用户的权限

ActiveUser activeUser = new ActiveUser();

activeUser.setRoles(roles);

activeUser.setUser(userBean);

activeUser.setMenus(menus);

activeUser.setUrls(urls);

activeUser.setPermissions(perms);

return new SimpleAuthenticationInfo(activeUser, token, getName());

}

@Override

public String login(String username, String password) {

String token;

User user = findUserByName(username);

if (user != null) {

String salt = user.getSalt();

//秘钥为盐

String target = MD5Utils.md5Encryption(password, salt);

//生成Token

token = JWTUtils.sign(username, target);

JWTToken jwtToken = new JWTToken(token);

try {

SecurityUtils.getSubject().login(jwtToken);

} catch (AuthenticationException e) {

throw new ServiceException(e.getMessage());

}

} else {

throw new ServiceException(ErrorCodeEnum.USER_ACCOUNT_NOT_FOUND);

}

return token;

}

4.Token的优缺点

优点：

支持跨域访问: Cookie是不允许垮域访问的，token支持；
无状态： token无状态，session有状态的；
去耦: 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在你的API被调用的时候，你可以进行Token生成调用即可；
更适用于移动应用: Cookie不支持手机端访问的；
性能: 在网络传输的过程中，性能更好；
基于标准化: 你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如： Firebase,Google, Microsoft）。

缺点：

占带宽，正常情况下要比 session_id 更大，需要消耗更多流量，挤占更多带宽，假如你的网站每月有 10 万次的浏览器，就意味着要多开销几十兆的流量。听起来并不多，但日积月累也是不小一笔开销。实际上，许多人会在 JWT 中存储的信息会更多；
无法在服务端注销，那么久很难解决劫持问题；
性能问题，JWT 的卖点之一就是加密签名，由于这个特性，接收方得以验证 JWT 是否有效且被信任。但是大多数 Web 身份认证应用中，JWT 都会被存储到 Cookie 中，这就是说你有了两个层面的签名。听着似乎很牛逼，但是没有任何优势，为此，你需要花费两倍的 CPU 开销来验证签名。对于有着严格性能要求的 Web 应用，这并不理想，尤其对于单线程环境。

作者：初念初恋
链接：https://juejin.cn/post/6984210017398292487
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

这篇关于一文彻底弄懂cookie、session、token的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！

C/C++教程