Sa-TokenSa-Token
主题
首页文档博客
视频
乐之者java(登录认证/权限管理/apiKey等)抓蛙师(23集)朱老师的小课堂(7集)王清江唷 SSO篇(29集)fox说技术(7集)架构驿站(11集)王清江唷(99集)筑梦信仰-joy(20集)达达-Java(26集)晒太阳的盐(22集)[ + 课程提交 ]
案例
Gitee - Awesome-Sa-TokenGitHub - Awesome-Sa-TokenAtomGit - Awesome-Sa-Token
加群需求提交赞助🔥 SSO/OAuth2 商业版
安全推荐
开发者安全 ChecklistAPI 安全 Checklist腾讯代码安全指南Web 安全学习笔记OWASP Cheat Sheet SeriesPayloadsAllTheThings
相关资源
更新日志常见报错推荐公众号在线考试在线提问问卷调查
  • 开始

    • 框架介绍
    • 在 SpringBoot 环境集成
    • 在 WebFlux 环境集成
    • 在 Solon 环境集成
    • 其它环境集成示例
    • 源码运行指南
    • Sa-Token 集成示例大全下载
  • 基础

    • 登录认证
    • 权限认证
    • 踢人下线
    • 注解鉴权
    • 路由拦截鉴权
    • Session会话
    • 框架配置
  • 深入

    • 集成 Redis
    • 前后端分离
    • 自定义 Token 风格
    • Token 提交前缀
    • 同端互斥登录
    • 记住我模式
    • 登录参数 & 注销参数
    • 二级认证
    • 模拟他人 & 身份切换
    • 账号封禁
    • 密码加密
    • 会话查询
    • Http Basic/Digest 认证
    • 全局侦听器
    • 全局过滤器
    • 多账号认证
  • 单点登录

    • 单点登录简述
    • 搭建统一认证中心:SSO-Server
    • SSO-Server 认证中心开放 API 接口
    • SSO模式一 共享Cookie同步会话
    • SSO模式二 URL重定向传播会话
    • SSO模式三 Http请求获取会话
    • 配置域名校验
    • 定制化登录页面
    • 自定义API路由
    • 平台中心跳转模式
    • 匿名 client 接入
    • 单点注销
    • 前后端分离下的整合方案
    • 消息推送机制
    • 用户数据同步 / 迁移
    • NoSdk、ReSdk 模式与非 java 项目
    • SSO 代码 API 参考
    • 常见问题总结
    • Sa-Pro:单点登录商业版
  • OAuth2.0

    • OAuth2.0简述
    • OAuth2-Server搭建
    • OAuth2-Server端开放 API 接口
    • 自定义数据加载器
    • 配置 client 域名校验
    • 自定义 Scope 权限及处理器
    • 为 Scope 划分等级
    • 自定义 grant_type
    • 定制化登录页面与授权页面
    • 自定义 API 路由
    • OAuth2-Server端前后台分离
    • OpenId 与 UnionId
    • 开启 OIDC 协议
    • 使用注解校验 Access-Token
    • OAuth2-与登录会话实现数据互通
    • OAuth2 代码 API 参考
    • 常见问题总结
    • Sa-Max:统一认证商业版
  • 微服务

    • 分布式Session会话
    • 网关统一鉴权
    • 内部服务外网隔离
    • 依赖引入说明
  • 插件

    • AOP注解鉴权
    • 临时 Token 认证
    • Quick-Login快速登录插件
    • Alone独立Redis插件
    • Alone独立Redisson插件
    • 缓存层扩展
    • JSON 序列化扩展
    • 序列化插件扩展包
    • HTTP 请求扩展
    • 和 Thymeleaf 集成
    • 和 Freemarker 集成
    • 注解鉴权 SpEL 表达式
    • 和 jwt 集成
    • 和 Dubbo 集成
    • 和 gRPC 集成
    • API 接口参数签名
    • API Key 接口调用秘钥
    • Sa-Token 插件开发指南
    • 自定义 SaTokenContext 指南
  • API手册

    • StpUtil-鉴权工具类
    • SaSession-会话对象
    • SaTokenDao-数据持久接口
    • SaStrategy-全局策略
    • 全局类、方法
  • 框架设计

    • 仓库目录
    • 数据结构
  • 其它

    • 更新日志
    • 框架生态
    • 框架博客
    • 推荐公众号
    • 加入讨论群
    • Sa-Token 内容合作群
    • 赞助 Sa-Token
    • 需求提交
    • 问卷调查
  • 附录

    • 常见问题排查
    • 框架名词解释
    • Sa-Token功能结构图
    • 全局 Log 输出
    • 异步 & Mock 上下文
    • 未登录场景值详解
    • Token有效期详解
    • Session模型详解
    • 数据读写三大作用域
    • TokenInfo参数详解
    • 异常细分状态码
    • 自定义注解
    • 防火墙
    • 参考:把权限放在缓存里
    • 参考:把路由拦截鉴权动态化
    • 解决反向代理 uri 丢失的问题
    • 解决跨域问题
    • 技术选型:SSO 与 OAuth2 对比
    • 集成 MongoDB 参考一
    • 集成 MongoDB 参考二
    • 从 Shiro、SpringSecurity、JWT 迁移
    • issue 提问模板
    • 为Sa-Token贡献代码
    • Sa-Token开源大事记
    • 团队成员
    • Sa-Token框架掌握度--在线考试







----- 到底线了 -----

×

一个项目搞定:同域、跨域、共享Redis、跨Redis、前后端一体、前后端分离、纯 js、vue2、vue3、非 Sa-Token 项目、非 java 项目等架构下的 SSO 认证需求。

一次购买,永久授权。全源码交付,不含密 Jar。提供售后技术支持。

多账号认证 ​


1、需求场景 ​

有的时候,我们会在一个项目中设计两套账号体系,比如一个电商系统的 user表 和 admin表, 在这种场景下,如果两套账号我们都使用 StpUtil 类的API进行登录鉴权,那么势必会发生逻辑冲突。

在Sa-Token中,这个问题的模型叫做:多账号体系认证。

要解决这个问题,我们必须有一个合理的机制将这两套账号的授权给区分开,让它们互不干扰才行。

2、演进思路 ​

假如说我们的 user表 和 admin表 都有一个 id=10001 的账号,它们对应的登录代码:StpUtil.login(10001) 是一样的, 那么问题来了:在StpUtil.getLoginId()获取到的账号id如何区分它是User用户,还是Admin用户?

你可能会想到为他们加一个固定前缀,比如StpUtil.login("User_" + 10001)、StpUtil.login("Admin_" + 10001),这样确实是可以解决问题的, 但是同样的:你需要在StpUtil.getLoginId()时再裁剪掉相应的前缀才能获取真正的账号id,这样一增一减就让我们的代码变得无比啰嗦。

那么,有没有从框架层面支持的,更优雅的解决方案呢?

3、解决方案 ​

前面几篇介绍的api调用,都是经过 StpUtil 类的各种静态方法进行授权认证, 而如果我们深入它的源码,点此阅览
就会发现,此类并没有任何代码逻辑,唯一做的事就是对成员变量stpLogic的各个API包装一下进行转发。

这样做有两个好处:

  • StpLogic 类的所有函数都可以被重写,按需扩展。
  • 在构造方法时随意传入一个不同的 loginType,就可以再造一套账号登录体系。

4、操作示例 ​

比如说,对于原生StpUtil类,我们只做admin账号权限认证,而对于user账号,我们则:

  1. 新建一个新的权限认证类,比如: StpUserUtil.java。
  2. 将StpUtil.java类的全部代码复制粘贴到 StpUserUtil.java里。
  3. 更改一下其 LoginType, 比如:
java
public class StpUserUtil {
	
	/**
	 * 账号体系标识 
	 */
	public static final String TYPE = "user";	// 将 LoginType 从`login`改为`user` 

	// 其它代码 ... 

}
1
2
3
4
5
6
7
8
9
10

成品样例参考:码云 StpUserUtil.java

4、接下来就可以像调用StpUtil.java一样调用 StpUserUtil.java了,这两套账号认证的逻辑是完全隔离的。例如:

java
// 凡是在 StpUtil 上有的方法,都可以在 StpUserUtil 上调用 
StpUserUtil.login(10001);    // 在当前会话以10001账号进行登录 
StpUserUtil.checkLogin();    // 校验当前账号是否以 User 身份进行登录 
StpUserUtil.getSession();    // 获取当前 User 账号的 Access-Session 对象 
StpUserUtil.checkPermission('xx');    // 校验当前登录的 user 账号是否具有 xx 权限 
// ...
1
2
3
4
5
6

5、Kit模式 ​

如果你觉得 “复制代码” 的方式繁琐不够优雅,这里还有另一种方案:建立一个 StpKit.java 门面类,声明所有的 StpLogic 引用:

java
/**
 * StpLogic 门面类,管理项目中所有的 StpLogic 账号体系
 */
public class StpKit {

    /**
     * 默认原生会话对象
     */
    public static final StpLogic DEFAULT = StpUtil.stpLogic;

    /**
     * Admin 会话对象,管理 Admin 表所有账号的登录、权限认证
     */
    public static final StpLogic ADMIN = new StpLogic("admin");

    /**
     * User 会话对象,管理 User 表所有账号的登录、权限认证
     */
    public static final StpLogic USER = new StpLogic("user");

    /**
     * XX 会话对象,(项目中有多少套账号表,就声明几个 StpLogic 会话对象)
     */
    public static final StpLogic XXX = new StpLogic("xx");

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

在需要登录、权限认证的地方:

java
// 在当前会话进行 Admin 账号登录
StpKit.ADMIN.login(10001);

// 在当前会话进行 User 账号登录
StpKit.USER.login(10001);

// 检测当前会话是否以 Admin 账号登录,并具有 article:add 权限
StpKit.ADMIN.checkPermission("article:add");

// 检测当前会话是否以 User 账号登录,并通过了二级认证
StpKit.USER.checkSafe();

// 获取当前 User 会话的 Session 对象,并进行写值操作 
StpKit.USER.getSession().set("name", "zhang");
1
2
3
4
5
6
7
8
9
10
11
12
13
14

6、在多账户模式下使用注解鉴权 ​

框架默认的注解鉴权 如@SaCheckLogin 只针对原生StpUtil进行鉴权。

例如,我们在一个方法上加上@SaCheckLogin注解,这个注解只会放行通过StpUtil.login(id)进行登录的会话, 而对于通过StpUserUtil.login(id)进行登录的会话,则始终不会通过校验。

那么如何告诉@SaCheckLogin要鉴别的是哪套账号的登录会话呢?很简单,你只需要指定一下注解的type属性即可:

java
// 通过type属性指定此注解校验的是我们自定义的`StpUserUtil`,而不是原生`StpUtil`
@SaCheckLogin(type = StpUserUtil.TYPE)
@RequestMapping("info")
public String info() {
    return "查询用户信息";
}
1
2
3
4
5
6

注:@SaCheckRole("xxx")、@SaCheckPermission("xxx")同理,亦可根据type属性指定其校验的账号体系,此属性默认为"",代表使用原生StpUtil账号体系。

7、使用注解合并简化代码 ​

交流群里有同学反应,虽然可以根据 @SaCheckLogin(type = "user") 指定账号类型,但几十上百个注解都加上这个的话,还是有些繁琐,代码也不够优雅,有么有更简单的解决方案?

我们期待一种[注解继承/合并]的能力,即:自定义一个注解,标注上@SaCheckLogin(type = "user"), 然后在方法上标注这个自定义注解,效果等同于标注@SaCheckLogin(type = "user")。

很遗憾,JDK默认的注解处理器并没有提供这种[注解继承/合并]的能力,不过好在我们可以利用 Spring 的注解处理器,达到同样的目的。

  1. 重写Sa-Token默认的注解处理器:
java
@Configuration
public class SaTokenConfigure {
    @PostConstruct
    public void rewriteSaStrategy() {
    	// 重写Sa-Token的注解处理器,增加注解合并功能 
		SaAnnotationStrategy.instance.getAnnotation = (element, annotationClass) -> {
			return AnnotatedElementUtils.getMergedAnnotation(element, annotationClass); 
		};
    }
}
1
2
3
4
5
6
7
8
9
10
  1. 自定义一个注解:
java
/**
 * 登录认证(User版):只有登录之后才能进入该方法 
 * <p> 可标注在函数、类上(效果等同于标注在此类的所有方法上) 
 */
@SaCheckLogin(type = "user")
@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.METHOD, ElementType.TYPE})
public @interface SaUserCheckLogin {
	
}
1
2
3
4
5
6
7
8
9
10
  1. 接下来就可以使用我们的自定义注解了:
java
// 使用 @SaUserCheckLogin 的效果等同于使用:@SaCheckLogin(type = "user")
@SaUserCheckLogin
@RequestMapping("info")
public String info() {
    return "查询用户信息";
}
1
2
3
4
5
6

注:其它注解 @SaCheckRole("xxx")、@SaCheckPermission("xxx")同理, 完整示例参考 Gitee 代码: 注解合并。

自定义注解方案

除了注解合并方案,这里还有一份自定义注解方案,参考:自定义注解

8、同端多登陆 ​

假设我们不仅需要在后台同时集成两套账号,我们还需要在一个客户端同时登陆两套账号(业务场景举例:一个APP中可以同时登陆商家账号和用户账号)。

如果我们不做任何特殊处理的话,在客户端会发生token覆盖,新登录的 token 会覆盖掉旧登录的 token 从而导致旧登录失效。

具体表现大致为:在一个浏览器登录商家账号后,再登录用户账号,然后商家账号的登录态就会自动失效。

那么如何解决这个问题?很简单,我们只要更改一下 StpUserUtil 的 TokenName 即可,参考示例如下:

java
public class StpUserUtil {
	
	// 使用匿名子类 重写`stpLogic对象`的一些方法 
	public static StpLogic stpLogic = new StpLogic("user") {
		// 重写 StpLogic 类下的 `splicingKeyTokenName` 函数,返回一个与 `StpUtil` 不同的token名称, 防止冲突 
		@Override
		public String splicingKeyTokenName() {
			return super.splicingKeyTokenName() + "-user";
		}
		// 同理你可以按需重写一些其它方法 ... 
	}; 
	
	// ... 
	
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

再次调用 StpUserUtil.login(10001) 进行登录授权时,token的名称将不再是 satoken,而是我们重写后的 satoken-user,这样就不会再客户端发生 token 的相互覆盖了。

9、不同体系不同 SaTokenConfig 配置 ​

如果自定义的 StpUserUtil 需要使用不同 SaTokenConfig 对象, 也很简单,参考示例如下:

java
@Configuration
public class SaTokenConfigure {
	
	@PostConstruct
	public void setSaTokenConfig() {
		// 设定 StpUtil 使用的 SaTokenConfig 配置参数对象
		SaTokenConfig config1 = new SaTokenConfig();
		config1.setTokenName("satoken1");
		config1.setTimeout(1000);
		config1.setTokenStyle("random-64");
		// 更多设置 ... 
		StpUtil.stpLogic.setConfig(config1);

		// 设定 StpUserUtil 使用的 SaTokenConfig 配置参数对象
		SaTokenConfig config2 = new SaTokenConfig();
		config2.setTokenName("satoken2");
		config2.setTimeout(2000);
		config2.setTokenStyle("tik");
		// 更多设置 ... 
		StpUserUtil.stpLogic.setConfig(config2);
	}

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

10、多账号体系混合鉴权 ​

QQ群中经常有小伙伴提问:在多账号体系下,怎么在 SaInterceptor 拦截器中给一个接口登录鉴权?

其实这个问题,主要是靠你的业务需求来决定,以后台 Admin 账号和前台 User 账号为例:

java
// 注册 Sa-Token 拦截器
@Override
public void addInterceptors(InterceptorRegistry registry) {
	registry.addInterceptor(new SaInterceptor(handle -> {
		
		// 如果这个接口,要求客户端登录了后台 Admin 账号才能访问:
		SaRouter.match("/art/getInfo").check(r -> StpUtil.checkLogin());

		// 如果这个接口,要求客户端登录了前台 User 账号才能访问:
		SaRouter.match("/art/getInfo").check(r -> StpUserUtil.checkLogin());
		
		// 如果这个接口,要求客户端同时登录 Admin 和 User 账号,才能访问:
		SaRouter.match("/art/getInfo").check(r -> {
			StpUtil.checkLogin();
			StpUserUtil.checkLogin();
		});

		// 如果这个接口,要求客户端登录 Admin 和 User 账号任意一个,就能访问:
		SaRouter.match("/art/getInfo").check(r -> {
			if(StpUtil.isLogin() == false && StpUserUtil.isLogin() == false) {
				throw new SaTokenException("请登录后再访问接口");
			}
		});
		
	})).addPathPatterns("/**");
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

11、在一个接口里获取是哪个体系的账号正在登录 ​

可以分别用两个体系的 isLogin() 方法去判断,哪个返回 true 就代表正在登录哪个体系

java
@RequestMapping("test")
public SaResult test2() {
	
	String loginType = "";
	
	if(StpUtil.isLogin()) {
		loginType = StpUtil.getLoginType();
	}
	if(StpUserUtil.isLogin()) {
		loginType = StpUserUtil.getLoginType();
	}
	
	System.out.println("当前登录的 loginType:" + loginType);

	return SaResult.ok();
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

请注意此处可能出现的两种边际情况:

  • 两个 if 均返回 false:代表客户端在两个账号体系都没有登录。
  • 两个 if 均返回 true:代表客户端在两个账号体系都登录了。

12、注意点:运行时不可更改 LoginType ​

在 Q群 解决问题时,发现有些同学会写出类似下列形式的代码:

java
StpUtil.login(10001);
StpUtil.getStpLogic().setLoginType("user");
StpUtil.getSession().set("name", "zhangsan");
1
2
3

这是一种错误写法:LoginType 不可在运行时更改,只能在项目启动时指定。一旦项目启动成功后再修改 LoginType ,就会造成线程安全问题和严重的逻辑问题。


本章代码示例:Sa-Token 多账号体系认证 —— [ StpUserUtil.java ]









发现错误? 您可以在 Gitee 或 GitHub 或 AtomGit 帮助我们完善此页文档! 或 加入讨论群 交流反馈。

我们坚信,即使再复杂的技术,也可以用清晰、干练、易懂的文字描述出它的具体细节,如果你在阅读文档时有难以理解的章节,那一定是我们还没有优化好它, 请向我们 反馈 你的困惑之处,我们将持续优化文档。


鲁ICP备18046274号-5|公安备案鲁公网安备37011202002956号
目录

本页无章节

推荐关闭
Sa-Token 商业版:轻松搭建 SSO 单点登录、OAuth2.0 统一认证、API Key 认证。全源码交付、可二开。
加入 Sa-Token 框架交流群

离线版文档历史所有版本文档Demo 示例大全下载

如果 Sa-Token 帮助到了你,希望你可以向同事、朋友推荐了解本框架,这对我们非常重要,感谢支持!

加油,工程师!