后端技术选型 sa-token校验学习中文档学习

依赖

配置文件

登录验证

登录与注销

Cookie 自动注入

前后端分离(无 Cookie 模式)

何为 Cookie

何为无 Cookie 模式?

解决方案

1、后端将 token 返回到前端

2、前端将 token 提交到后端

其它解决方案？

自定义 Token 前缀

[ 记住我 ] 模式

前后端分离模式下如何实现[记住我]?

登录时指定 Token 有效期

Sa-Token 集成 Redis

方式1、Sa-Token 整合 Redis （使用 jdk 默认序列化方式）

方式2、Sa-Token 整合 Redis（使用 jackson 序列化方式）

集成 Redis 请注意：

权限认证

获取当前账号权限码集合

权限校验

角色校验

如何把权限精确到按钮级？

注意

路由拦截鉴权

校验函数详解

匹配特征详解

Session 会话

SaTokenInfo 参数详解

依赖

<!-- Sa-Token 权限认证，在线文档：https://sa-token.cc -->
<dependency><groupId>cn.dev33</groupId><artifactId>sa-token-spring-boot-starter</artifactId><version>1.39.0</version>
</dependency>

配置文件

############## Sa-Token 配置 (文档: https://sa-token.cc) ##############
sa-token: # token 名称（同时也是 cookie 名称）token-name: satoken# token 有效期（单位：秒） 默认30天，-1 代表永久有效timeout: 2592000# token 最低活跃频率（单位：秒），如果 token 超过此时间没有访问系统就会被冻结，默认-1 代表不限制，永不冻结active-timeout: -1# 是否允许同一账号多地同时登录 （为 true 时允许一起登录, 为 false 时新登录挤掉旧登录）is-concurrent: true# 在多人登录同一账号时，是否共用一个 token （为 true 时所有登录共用一个 token, 为 false 时每次登录新建一个 token）is-share: true# token 风格（默认可取值：uuid、simple-uuid、random-32、random-64、random-128、tik）token-style: uuid# 是否输出操作日志 is-log: true

登录验证

图解

登录与注销

// 会话登录：参数填写要登录的账号id，
// 建议的数据类型：long | int | String， 
// 不可以传入复杂类型，如：User、Admin 等等
StpUtil.login(Object id);

只此一句代码，便可以使会话登录成功，实际上，Sa-Token 在背后做了大量的工作，包括但不限于：

检查此账号是否之前已有登录；
为账号生成 Token 凭证与 Session 会话；
记录 Token 活跃时间；
通知全局侦听器，xx 账号登录成功；
将 Token 注入到请求上下文；
等等其它工作……

你暂时不需要完整了解整个登录过程，你只需要记住关键一点：

Sa-Token 为这个账号创建了一个Token凭证，且通过 Cookie 上下文返回给了前端。

Cookie 自动注入

StpUtil.login(id) 方法利用了 Cookie 自动注入的特性，省略了你手写返回 token 的代码。

Cookie 是什么？

如果你对 Cookie 功能还不太了解，也不用担心，我们会在之后的 [ 前后端分离 ] 章节中详细的阐述 Cookie 功能，现在你只需要了解最基本的两点：

Cookie 可以从后端控制往浏览器中写入 token 值。
Cookie 会在前端每次发起请求时自动提交 token 值。

因此，在 Cookie 功能的加持下，我们可以仅靠 StpUtil.login(id) 一句代码就完成登录认证。

前后端分离(无 Cookie 模式)

何为 Cookie

Cookie 是 Web 服务器生成并发送至 Web 浏览器的小型信息文件。

Web 浏览器在预定义的时间段内或在用户在网站上的会话期间存储收到的 Cookie。它们将相关的 Cookie 附加到用户今后向 Web 服务器提出的任何请求中。

Cookie 帮助网站了解用户的情况，使网站能够提供个性化的用户体验。例如，电子商务网站使用 Cookie 来了解用户在其购物车中放置了哪些商品。此外，一些 Cookie 对于维护安全必不可少，如身份验证 Cookie（见下文）。

在互联网上使用的 Cookie 也称为“HTTP Cookie”。与大部分网络一样，Cookie 是使用 HTTP 协议发送的。

何为无 Cookie 模式?

无 Cookie 模式：特指不支持 Cookie 功能的终端，通俗来讲就是我们常说的 —— 前后端分离模式。

常规 Web 端鉴权方法，一般由 Cookie模式 完成，而 Cookie 有两个特性：

可由后端控制写入。
每次请求自动提交。

这就使得我们在前端代码中，无需任何特殊操作，就能完成鉴权的全部流程（因为整个流程都是后端控制完成的）
而在app、小程序等前后端分离场景中，一般是没有 Cookie 这一功能的，此时大多数人都会一脸懵逼，咋进行鉴权啊？

见招拆招，其实答案很简单：

不能后端控制写入了，就前端自己写入。

（难点在后端如何将 Token 传递到前端）

每次请求不能自动提交了，那就手动提交。

（难点在前端如何将 Token 传递到后端，同时后端将其读取出来）

解决方案

1、后端将 token 返回到前端

首先调用 StpUtil.login(id) 进行登录。
调用 StpUtil.getTokenInfo() 返回当前会话的 token 详细参数。

- 此方法返回一个对象，其有两个关键属性：tokenName和tokenValue（token 的名称和 token 的值）。
- 将此对象传递到前台，让前端人员将这两个值保存到本地。

代码示例：

// 登录接口
@RequestMapping("doLogin")
public SaResult doLogin() {// 第1步，先登录上 StpUtil.login(10001);// 第2步，获取 Token  相关参数 SaTokenInfo tokenInfo = StpUtil.getTokenInfo();// 第3步，返回给前端 return SaResult.data(tokenInfo);
}

2、前端将 token 提交到后端

无论是app还是小程序，其传递方式都大同小异。
那就是，将 token 塞到请求header里，格式为：{tokenName: tokenValue}。
以经典跨端框架 uni-app 为例：

方式1，简单粗暴

// 1、首先在登录时，将 tokenValue 存储在本地，例如：
uni.setStorageSync('tokenValue', tokenValue);// 2、在发起ajax请求的地方，获取这个值，并塞到header里 
uni.request({url: 'https://www.example.com/request', // 仅为示例，并非真实接口地址。header: {"content-type": "application/x-www-form-urlencoded","satoken": uni.getStorageSync('tokenValue')        // 关键代码, 注意参数名字是 satoken },success: (res) => {console.log(res.data);    }
});

方式2，更加灵活

// 1、首先在登录时，将tokenName和tokenValue一起存储在本地，例如：
uni.setStorageSync('tokenName', tokenName); 
uni.setStorageSync('tokenValue', tokenValue); // 2、在发起ajax的地方，获取这两个值, 并组织到head里 
var tokenName = uni.getStorageSync('tokenName');    // 从本地缓存读取tokenName值
var tokenValue = uni.getStorageSync('tokenValue');    // 从本地缓存读取tokenValue值
var header = {"content-type": "application/x-www-form-urlencoded"
};
if (tokenName != undefined && tokenName != '') {header[tokenName] = tokenValue;
}// 3、后续在发起请求时将 header 对象塞到请求头部 
uni.request({url: 'https://www.example.com/request', // 仅为示例，并非真实接口地址。header: header,success: (res) => {console.log(res.data);    }
});

只要按照如此方法将token值传递到后端，Sa-Token 就能像传统PC端一样自动读取到 token 值，进行鉴权。
你可能会有疑问，难道我每个ajax都要写这么一坨？岂不是麻烦死了？

- 你当然不能每个 ajax 都写这么一坨，因为这种重复性代码都是要封装在一个函数里统一调用的。

其它解决方案？

如果你对 Cookie 非常了解，那你就会明白，所谓 Cookie ，本质上就是一个特殊的header参数而已，而既然它只是一个 header 参数，我们就能手动模拟实现它，从而完成鉴权操作。

自定义 Token 前缀

sa-token: # token前缀token-prefix: Bearer

此时后端如果不做任何特殊处理，框架将会把Bearer 视为token的一部分，无法正常读取token信息，导致鉴权失败。

{"satoken": "Bearer xxxx-xxxx-xxxx-xxxx"
}

为此，我们需要在yml中添加如下配置：
此时 Sa-Token 便可在读取 Token 时裁剪掉 Bearer，成功获取xxxx-xxxx-xxxx-xxxx。
注意点

Token前缀与 Token值之间必须有一个空格。
一旦配置了 Token前缀，则前端提交 Token 时，必须带有前缀，否则会导致框架无法读取 Token。
由于Cookie中无法存储空格字符，所以配置 Token 前缀后，Cookie 模式将会失效，此时只能将 Token 提交到header里进行传输。

[ 记住我 ] 模式

如图所示，一般网站的登录界面都会有一个 [记住我] 按钮，当你勾选它登录后，即使你关闭浏览器再次打开网站，也依然会处于登录状态，无须重复验证密码：

Cookie作为浏览器提供的默认会话跟踪机制，其生命周期有两种形式，分别是：

临时Cookie：有效期为本次会话，只要关闭浏览器窗口，Cookie就会消失。
持久Cookie：有效期为一个具体的时间，在时间未到期之前，即使用户关闭了浏览器Cookie也不会消失。

利用Cookie的此特性，我们便可以轻松实现 [记住我] 模式：

勾选 [记住我] 按钮时：调用StpUtil.login(10001, true)，在浏览器写入一个持久Cookie储存 Token，此时用户即使重启浏览器 Token 依然有效。
不勾选 [记住我] 按钮时：调用StpUtil.login(10001, false)，在浏览器写入一个临时Cookie储存 Token，此时用户在重启浏览器后 Token 便会消失，导致会话失效。

// 设置登录账号id为10001，第二个参数指定是否为[记住我]，当此值为false后，关闭浏览器后再次打开需要重新登录
StpUtil.login(10001, false);

前后端分离模式下如何实现[记住我]?

任何基于Cookie的认证方案在前后端分离环境下都会失效（原因在于这些客户端默认没有实现Cookie功能），不过好在，这些客户端一般都提供了替代方案，唯一遗憾的是，此场景中token的生命周期需要我们在前端手动控制

以经典跨端框架 uni-app 为例，我们可以使用如下方式达到同样的效果：

// 使用本地存储保存token，达到 [持久Cookie] 的效果
uni.setStorageSync("satoken", "xxxx-xxxx-xxxx-xxxx-xxx");// 使用globalData保存token，达到 [临时Cookie] 的效果
getApp().globalData.satoken = "xxxx-xxxx-xxxx-xxxx-xxx";

如果你决定在PC浏览器环境下进行前后端分离模式开发，那么更加简单：

// 使用 localStorage 保存token，达到 [持久Cookie] 的效果
localStorage.setItem("satoken", "xxxx-xxxx-xxxx-xxxx-xxx");// 使用 sessionStorage 保存token，达到 [临时Cookie] 的效果
sessionStorage.setItem("satoken", "xxxx-xxxx-xxxx-xxxx-xxx");

登录时指定 Token 有效期

登录时不仅可以指定是否为[记住我]模式，还可以指定一个特定的时间作为 Token 有效时长，如下示例：

// 示例1：
// 指定token有效期(单位: 秒)，如下所示token七天有效
StpUtil.login(10001, new SaLoginModel().setTimeout(60 * 60 * 24 * 7));// ----------------------- 示例2：所有参数
// `SaLoginModel`为登录参数Model，其有诸多参数决定登录时的各种逻辑，例如：
StpUtil.login(10001, new SaLoginModel().setDevice("PC")                // 此次登录的客户端设备类型, 用于[同端互斥登录]时指定此次登录的设备类型.setIsLastingCookie(true)        // 是否为持久Cookie（临时Cookie在浏览器关闭时会自动删除，持久Cookie在重新打开后依然存在）.setTimeout(60 * 60 * 24 * 7)    // 指定此次登录token的有效期, 单位:秒 （如未指定，自动取全局配置的 timeout 值）.setToken("xxxx-xxxx-xxxx-xxxx") // 预定此次登录的生成的Token .setIsWriteHeader(false)         // 是否在登录后将 Token 写入到响应头);

Sa-Token 集成 Redis

Sa-Token 默认将数据保存在内存中，此模式读写速度最快，且避免了序列化与反序列化带来的性能消耗，但是此模式也有一些缺点，比如：

重启后数据会丢失。
无法在分布式环境中共享数据。

为此，Sa-Token 提供了扩展接口，你可以轻松将会话数据存储在一些专业的缓存中间件上（比如 Redis），做到重启数据不丢失，而且保证分布式环境下多节点的会话一致性。

以下是框架提供的 Redis 集成包：

方式1、Sa-Token 整合 Redis （使用 jdk 默认序列化方式）

<!-- Sa-Token 整合 Redis （使用 jdk 默认序列化方式） -->
<dependency><groupId>cn.dev33</groupId><artifactId>sa-token-redis</artifactId><version>1.39.0</version>
</dependency>

优点：兼容性好，缺点：Session 序列化后基本不可读，对开发者来讲等同于乱码。

方式2、Sa-Token 整合 Redis（使用 jackson 序列化方式）

<!-- Sa-Token 整合 Redis （使用 jackson 序列化方式） -->
<dependency><groupId>cn.dev33</groupId><artifactId>sa-token-redis-jackson</artifactId><version>1.39.0</version>
</dependency>

优点：Session 序列化后可读性强，可灵活手动修改，缺点：兼容性稍差。

集成 Redis 请注意：

1. 无论使用哪种序列化方式，你都必须为项目提供一个 Redis 实例化方案，例如：

<!-- 提供Redis连接池 -->
<dependency><groupId>org.apache.commons</groupId><artifactId>commons-pool2</artifactId>
</dependency>

2. 引入了依赖，我还需要为 Redis 配置连接信息吗？
需要！只有项目初始化了正确的 Redis 实例，Sa-Token才可以使用 Redis 进行数据持久化，参考以下yml配置

3. 集成 Redis 后，是我额外手动保存数据，还是框架自动保存？
框架自动保存。集成 Redis 只需要引入对应的 pom依赖 即可，框架所有上层 API 保持不变。

4. 集成包版本问题
Sa-Token-Redis 集成包的版本尽量与 Sa-Token-Starter 集成包的版本一致，否则可能出现兼容性问题。

权限认证

深入到底层数据中，就是每个账号都会拥有一组权限码集合，框架来校验这个集合中是否包含指定的权限码。

例如：当前账号拥有权限码集合 ["user-add", "user-delete", "user-get"]，这时候我来校验权限 "user-update"，则其结果就是：验证失败，禁止访问。

获取当前账号权限码集合

因为每个项目的需求不同，其权限设计也千变万化，因此 [ 获取当前账号权限码集合 ] 这一操作不可能内置到框架中，所以 Sa-Token 将此操作以接口的方式暴露给你，以方便你根据自己的业务逻辑进行重写。

你需要做的就是新建一个类，实现 StpInterface接口，例如以下代码：

/*** 自定义权限加载接口实现类*/
@Component    // 保证此类被 SpringBoot 扫描，完成 Sa-Token 的自定义权限验证扩展 
public class StpInterfaceImpl implements StpInterface {/*** 返回一个账号所拥有的权限码集合 */@Overridepublic List<String> getPermissionList(Object loginId, String loginType) {// 本 list 仅做模拟，实际项目中要根据具体业务逻辑来查询权限List<String> list = new ArrayList<String>();    list.add("101");list.add("user.add");list.add("user.update");list.add("user.get");// list.add("user.delete");list.add("art.*");return list;}/*** 返回一个账号所拥有的角色标识集合 (权限与角色可分开校验)*/@Overridepublic List<String> getRoleList(Object loginId, String loginType) {// 本 list 仅做模拟，实际项目中要根据具体业务逻辑来查询角色List<String> list = new ArrayList<String>();    list.add("admin");list.add("super-admin");return list;}}

参数解释：

loginId：账号id，即你在调用 StpUtil.login(id) 时写入的标识值。
loginType：账号体系标识，此处可以暂时忽略，在 [ 多账户认证 ] 章节下会对这个概念做详细的解释。

权限校验

然后就可以用以下 api 来鉴权了

// 获取：当前账号所拥有的权限集合
StpUtil.getPermissionList();// 判断：当前账号是否含有指定权限, 返回 true 或 false
StpUtil.hasPermission("user.add");        // 校验：当前账号是否含有指定权限, 如果验证未通过，则抛出异常: NotPermissionException 
StpUtil.checkPermission("user.add");        // 校验：当前账号是否含有指定权限 [指定多个，必须全部验证通过]
StpUtil.checkPermissionAnd("user.add", "user.delete", "user.get");        // 校验：当前账号是否含有指定权限 [指定多个，只要其一验证通过即可]
StpUtil.checkPermissionOr("user.add", "user.delete", "user.get");

扩展：NotPermissionException 对象可通过 getLoginType() 方法获取具体是哪个 StpLogic 抛出的异常

角色校验

在 Sa-Token 中，角色和权限可以分开独立验证

// 获取：当前账号所拥有的角色集合
StpUtil.getRoleList();// 判断：当前账号是否拥有指定角色, 返回 true 或 false
StpUtil.hasRole("super-admin");        // 校验：当前账号是否含有指定角色标识, 如果验证未通过，则抛出异常: NotRoleException
StpUtil.checkRole("super-admin");        // 校验：当前账号是否含有指定角色标识 [指定多个，必须全部验证通过]
StpUtil.checkRoleAnd("super-admin", "shop-admin");        // 校验：当前账号是否含有指定角色标识 [指定多个，只要其一验证通过即可] 
StpUtil.checkRoleOr("super-admin", "shop-admin");

扩展：NotRoleException 对象可通过 getLoginType() 方法获取具体是哪个 StpLogic 抛出的异常

上帝权限

当一个账号拥有 "*" 权限时，他可以验证通过任何权限码（角色认证同理）

如何把权限精确到按钮级？

权限精确到按钮级的意思就是指：权限范围可以控制到页面上的每一个按钮是否显示。

思路：如此精确的范围控制只依赖后端已经难以完成，此时需要前端进行一定的逻辑判断。

如果是前后端一体项目，可以参考：Thymeleaf 标签方言，如果是前后端分离项目，则：

在登录时，把当前账号拥有的所有权限码一次性返回给前端。
前端将权限码集合保存在localStorage或其它全局状态管理对象中。
在需要权限控制的按钮上，使用 js 进行逻辑判断，例如在Vue框架中我们可以使用如下写法：

// `arr`是当前用户拥有的权限码数组
// `user.delete`是显示按钮需要拥有的权限码
// `删除按钮`是用户拥有权限码才可以看到的内容。
<button v-if="arr.indexOf('user.delete') > -1">删除按钮</button>

注意

前端有了鉴权后端还需要鉴权吗？

需要！
前端的鉴权只是一个辅助功能，对于专业人员这些限制都是可以轻松绕过的，为保证服务器安全：无论前端是否进行了权限校验，后端接口都需要对会话请求再次进行权限校验！

路由拦截鉴权

假设我们有如下需求：

需求场景

项目中所有接口均需要登录认证，只有 “登录接口” 本身对外开放

我们怎么实现呢？给每个接口加上鉴权注解？手写全局拦截器？似乎都不是非常方便。

在这个需求中我们真正需要的是一种基于路由拦截的鉴权模式，那么在Sa-Token怎么实现路由拦截鉴权呢？

注册 Sa-Token 路由拦截器

@Configuration
public class SaTokenConfigure implements WebMvcConfigurer {// 注册拦截器@Overridepublic void addInterceptors(InterceptorRegistry registry) {// 注册 Sa-Token 拦截器，校验规则为 StpUtil.checkLogin() 登录校验。registry.addInterceptor(new SaInterceptor(handle -> StpUtil.checkLogin())).addPathPatterns("/**").excludePathPatterns("/user/doLogin"); }
}

校验函数详解

自定义认证规则：new SaInterceptor(handle -> StpUtil.checkLogin()) 是最简单的写法，代表只进行登录校验功能。

我们可以往构造函数塞一个完整的 lambda 表达式，来定义详细的校验规则，例如：

@Configuration
public class SaTokenConfigure implements WebMvcConfigurer {@Overridepublic void addInterceptors(InterceptorRegistry registry) {// 注册 Sa-Token 拦截器，定义详细认证规则 registry.addInterceptor(new SaInterceptor(handler -> {// 指定一条 match 规则SaRouter.match("/**")    // 拦截的 path 列表，可以写多个 */.notMatch("/user/doLogin")        // 排除掉的 path 列表，可以写多个 .check(r -> StpUtil.checkLogin());        // 要执行的校验动作，可以写完整的 lambda 表达式// 根据路由划分模块，不同模块不同鉴权 SaRouter.match("/user/**", r -> StpUtil.checkPermission("user"));SaRouter.match("/admin/**", r -> StpUtil.checkPermission("admin"));SaRouter.match("/goods/**", r -> StpUtil.checkPermission("goods"));SaRouter.match("/orders/**", r -> StpUtil.checkPermission("orders"));SaRouter.match("/notice/**", r -> StpUtil.checkPermission("notice"));SaRouter.match("/comment/**", r -> StpUtil.checkPermission("comment"));})).addPathPatterns("/**");}
}

SaRouter.match() 匹配函数有两个参数：

参数一：要匹配的path路由。
参数二：要执行的校验函数。

在校验函数内不只可以使用 StpUtil.checkPermission("xxx") 进行权限校验，你还可以写任意代码，例如：

@Configuration
public class SaTokenConfigure implements WebMvcConfigurer {// 注册 Sa-Token 的拦截器@Overridepublic void addInterceptors(InterceptorRegistry registry) {// 注册路由拦截器，自定义认证规则 registry.addInterceptor(new SaInterceptor(handler -> {// 登录校验 -- 拦截所有路由，并排除/user/doLogin 用于开放登录 SaRouter.match("/**", "/user/doLogin", r -> StpUtil.checkLogin());// 角色校验 -- 拦截以 admin 开头的路由，必须具备 admin 角色或者 super-admin 角色才可以通过认证 SaRouter.match("/admin/**", r -> StpUtil.checkRoleOr("admin", "super-admin"));// 权限校验 -- 不同模块校验不同权限 SaRouter.match("/user/**", r -> StpUtil.checkPermission("user"));SaRouter.match("/admin/**", r -> StpUtil.checkPermission("admin"));SaRouter.match("/goods/**", r -> StpUtil.checkPermission("goods"));SaRouter.match("/orders/**", r -> StpUtil.checkPermission("orders"));SaRouter.match("/notice/**", r -> StpUtil.checkPermission("notice"));SaRouter.match("/comment/**", r -> StpUtil.checkPermission("comment"));// 甚至你可以随意的写一个打印语句SaRouter.match("/**", r -> System.out.println("----啦啦啦----"));// 连缀写法SaRouter.match("/**").check(r -> System.out.println("----啦啦啦----"));})).addPathPatterns("/**");}
}

匹配特征详解

除了上述示例的 path 路由匹配，还可以根据很多其它特征进行匹配，以下是所有可匹配的特征：

// 基础写法样例：匹配一个path，执行一个校验函数 
SaRouter.match("/user/**").check(r -> StpUtil.checkLogin());// 根据 path 路由匹配   ——— 支持写多个path，支持写 restful 风格路由 
// 功能说明: 使用 /user , /goods 或者 /art/get 开头的任意路由都将进入 check 方法
SaRouter.match("/user/**", "/goods/**", "/art/get/{id}").check( /* 要执行的校验函数 */ );// 根据 path 路由排除匹配 
// 功能说明: 使用 .html , .css 或者 .js 结尾的任意路由都将跳过, 不会进入 check 方法
SaRouter.match("/**").notMatch("*.html", "*.css", "*.js").check( /* 要执行的校验函数 */ );// 根据请求类型匹配 
SaRouter.match(SaHttpMethod.GET).check( /* 要执行的校验函数 */ );// 根据一个 boolean 条件进行匹配 
SaRouter.match( StpUtil.isLogin() ).check( /* 要执行的校验函数 */ );// 根据一个返回 boolean 结果的lambda表达式匹配 
SaRouter.match( r -> StpUtil.isLogin() ).check( /* 要执行的校验函数 */ );// 多个条件一起使用 
// 功能说明: 必须是 Get 请求 并且 请求路径以 `/user/` 开头 
SaRouter.match(SaHttpMethod.GET).match("/user/**").check( /* 要执行的校验函数 */ );// 可以无限连缀下去 
// 功能说明: 同时满足 Get 方式请求, 且路由以 /admin 开头, 路由中间带有 /send/ 字符串, 路由结尾不能是 .js 和 .css
SaRouter.match(SaHttpMethod.GET).match("/admin/**").match("/**/send/**") .notMatch("/**/*.js").notMatch("/**/*.css")// .....check( /* 只有上述所有条件都匹配成功，才会执行最后的check校验函数 */ );

Sa-Token

Session 会话

SaSession 与 HttpSession 没有任何关系，在HttpSession上写入的值，在SaSession中无法取出
HttpSession并未被框架接管，在使用Sa-Token时，请在任何情况下均使用SaSession，不要使用HttpSession

Session 是会话中专业的数据缓存组件，通过 Session 我们可以很方便的缓存一些高频读写数据，提高程序性能，例如：

// 在登录时缓存 user 对象 
StpUtil.getSession().set("user", user);// 然后我们就可以在任意处使用这个 user 对象
SysUser user = (SysUser) StpUtil.getSession().get("user");

在 Sa-Token 中，Session 分为三种，分别是：

Account-Session: 指的是框架为每个账号id 分配的 Session
Token-Session: 指的是框架为每个 token 分配的 Session
Custom-Session: 指的是以一个特定的值作为SessionId，来分配的 Session

提起Session，你脑海中最先浮现的可能就是 JSP 中的 HttpSession，它的工作原理可以大致总结为：

客户端每次与服务器第一次握手时，会被强制分配一个 [唯一id] 作为身份标识，注入到 Cookie 之中，之后每次发起请求时，客户端都要将它提交到后台，服务器根据 [唯一id] 找到每个请求专属的Session对象，维持会话

这种机制简单粗暴，却有N多明显的缺点：

同一账号分别在PC、APP登录，会被识别为两个不相干的会话
一个设备难以同时登录两个账号
每次一个新的客户端访问服务器时，都会产生一个新的Session对象，即使这个客户端只访问了一次页面
在不支持Cookie的客户端下，这种机制会失效

Sa-Token Session可以理解为 HttpSession 的升级版：

Sa-Token只在调用StpUtil.login(id)登录会话时才会产生Session，不会为每个陌生会话都产生Session，节省性能
在登录时产生的Session，是分配给账号id的，而不是分配给指定客户端的，也就是说在PC、APP上登录的同一账号所得到的Session也是同一个，所以两端可以非常轻松的同步数据
Sa-Token支持Cookie、Header、body三个途径提交Token，而不是仅限于Cookie
由于不强依赖Cookie，所以只要将Token存储到不同的地方，便可以做到一个客户端同时登录多个账号

// 获取当前会话的 Account-Session 
SaSession session = StpUtil.getSession();// 从 Account-Session 中读取、写入数据 
session.get("name");
session.set("name", "张三");

三种Session创建时机：

Account-Session: 指的是框架为每个账号id 分配的 Session
Token-Session: 指的是框架为每个 token 分配的 Session
Custom-Session: 指的是以一个特定的值作为SessionId，来分配的 Session

Sa-Token

简而言之：

Account-Session 以账号 id 为主，只要 token 指向的账号 id 一致，那么对应的Session对象就一致
Token-Session 以token为主，只要token不同，那么对应的Session对象就不同
Custom-Session 以特定的key为主，不同key对应不同的Session对象，同样的key指向同一个Session对象

SaTokenInfo 参数详解

{"code": 200,"msg": "ok","data": {"tokenName": "satoken",           // token名称"tokenValue": "e67b99f1-3d7a-4a8d-bb2f-e888a0805633",      // token值"isLogin": true,                  // 此token是否已经登录"loginId": "10001",               // 此token对应的LoginId，未登录时为null"loginType": "login",              // 账号类型标识"tokenTimeout": 2591977,          // token剩余有效期 (单位: 秒)"sessionTimeout": 2591977,        // Account-Session剩余有效时间 (单位: 秒)"tokenSessionTimeout": -2,        // Token-Session剩余有效时间 (单位: 秒) (-2表示系统中不存在这个缓存)"tokenActiveTimeout": -1,         // token 距离被冻结还剩的时间 (单位: 秒)"loginDevice": "default-device"   // 登录设备类型 },
}