整合文章：


文章目录

一、session的状态保持及弊端

当用户第一次通过浏览器使用用户名和密码访问服务器时，

  • 服务器会验证用户数据，
  • <mark>验证成功后在服务器端写入session数据</mark>，
  • <mark>向客户端浏览器返回sessionid，浏览器将sessionid保存在cookie中</mark>，
  • <mark>当用户再次访问服务器时，会携带sessionid</mark>，
  • 服务器会拿着sessionid从 数据库 内存（缓存） 获取session数据，然后进行用户信息查询，
  • 查询到，就会将查询到的用户信息返回，从而实现状态保持。

弊端：

  1. 服务器压力增大
    <mark>通常session是存储在内存中的</mark>，每个用户通过认证之后都会将session数据保存在服务器的内存中，而当用户量增大时，服务器的压力增大。

  2. CSRF跨站伪造请求攻击
    session是基于cookie进行用户识别的, <mark>cookie如果被截获（虽然同源机制，cookie不容易被获取 ）</mark>，用户就会很容易受到跨站请求伪造的攻击。

  3. 扩展性不强（<mark>这个是重点</mark>）
    如果将来搭建了多个服务器，虽然每个服务器都执行的是同样的业务逻辑，<mark>但是session数据是保存在内存中的（不是共享的）</mark>，用户第一次访问的是服务器1，当用户再次请求时可能访问的是另外一台服务器2，服务器2获取不到session信息，就判定用户没有登陆过。

二、token认证机制

token与session的不同主要在

  1. <mark>认证成功后，会对当前用户数据进行加密，生成一个加密字符串token，返还给客户端（服务器端并不进行保存）</mark>

  2. <mark>浏览器会将接收到的token值存储在Local Storage中，</mark>
    （通过js代码写入Local Storage，通过js获取，并不会像cookie一样自动携带）

  3. 再次访问时服务器端对token值的处理：

    1. 服务器对浏览器传来的token值进行解密，
    2. 解密完成后进行用户数据的查询，如果查询成功，则通过认证，实现状态保持，

所以，即时有了多台服务器，<mark>服务器也只是做了token的解密和用户数据的查询，它不需要在服务端去保留用户的认证信息或者会话信息</mark>，

这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利，解决了session扩展性的弊端。

Apache Shiro 用户信息保存在 Session 方案

shiro会自动将用户信息存储在shiro的 Session 中，如下图，取出Session中信息则可以通过User user = (User) SecurityUtils.getSubject().getPrincipal()获取！