Sa-Token マルチアカウント認証: システムの管理者アカウントとユーザー アカウントの認証操作を同時に提供します。

Sa-Token は軽量の Java 権限認証フレームワークであり、主にログイン認証、権限認証、シングル サインオン、OAuth2、マイクロサービス ゲートウェイ認証などの一連の権限関連の問題を解決します。

Gitee オープンソース アドレス: gitee.com/dromara/sa-…

この記事では、Sa-Tokenにおけるマルチアカウント認証の運用について紹介します。

1. 需要分析

電子商取引システムのユーザー テーブルと管理者テーブルなど、1 つのプロジェクトで 2 つのアカウント システムを設計する場合がありますが、このシナリオで両方のアカウント セットのログイン認証に StpUtil API を使用すると、論理的な競合が必然的に発生します。

Sa-Token では、この問題のモデルはマルチアカウント システム認証と呼ばれています。

この問題を解決するには、これら 2 つのアカウントの認証を分離して、相互に干渉しないようにする合理的なメカニズムが必要です。

2. 進化のアイデア

user テーブルと admin テーブルの両方に id=10001 のアカウントがあり、対応するログイン コードがStpUtil.login(10001)同じだとすると、StpUtil.getLoginId()取得したアカウント ID が User ユーザーであるか Admin ユーザーであるかをどのように区別するかという疑問が生じます。

StpUtil.login("User_" + 10001),などの固定プレフィックスを追加することを考えるかもしれませんStpUtil.login("Admin_" + 10001)。これで問題は実際に解決できますが、同じです。StpUtil.getLoginId()実際のアカウント ID を取得するには、対応するプレフィックスを切り取る必要があるため、コードが非常に冗長になります。

では、フレームワーク レベルからサポートされる、より洗練されたソリューションはあるのでしょうか?

SaManagerStpLogic を動的に作成する機能を提供します。

// 在当前会话登录 Admin 账号 10001
SaManager.getStpLogic("admin").login(10001);

// 在当前会话登录 User 账号 10001
SaManager.getStpLogic("user").login(10001);

これは解決策ですが、メソッドを呼び出すたびにアカウント タイプ パラメーターを指定する必要があり、コードが少し長くなっています。次に、2 番目の解決策である StpUtil 認証ツール クラスのカスタマイズを紹介します。

3. StpUtil 認証ツール クラスをカスタマイズする

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

这样做有两个优点:

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

四、操作示例

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

1. 新建一个新的权限认证类，比如： StpUserUtil.java。
2. 将StpUtil.java类的全部代码复制粘贴到 StpUserUtil.java里。
3. 更改一下其 LoginType， 比如：

public class StpUserUtil {
	
	/**
	 * 账号体系标识 
	 */
	public static final String TYPE = "user";	// 将 LoginType 从`login`改为`user` 

	// 其它代码 ... 

}

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

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

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

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

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

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

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

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

六、使用注解合并简化代码

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

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

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

1、重写Sa-Token默认的注解处理器：

@Configuration
public class SaTokenConfigure {
    @Autowired
    public void rewriteSaStrategy() {
    	// 重写Sa-Token的注解处理器，增加注解合并功能 
		SaStrategy.me.getAnnotation = (element, annotationClass) -> {
			return AnnotatedElementUtils.getMergedAnnotation(element, annotationClass); 
		};
    }
}

2、自定义一个注解：

/**
 * 登录认证(User版)：只有登录之后才能进入该方法 
 * <p> 可标注在函数、类上（效果等同于标注在此类的所有方法上） 
 */
@SaCheckLogin(type = "user")
@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.METHOD, ElementType.TYPE})
public @interface SaUserCheckLogin {
	
}

3、接下来就可以使用我们的自定义注解了：

// 使用 @SaUserCheckLogin 的效果等同于使用：@SaCheckLogin(type = "user")
@SaUserCheckLogin
@RequestMapping("info")
public String info() {
    return "查询用户信息";
}

注：其它注解 @SaCheckRole("xxx")、@SaCheckPermission("xxx")同理， 完整示例参考：码云：自定义注解。

七、同端多登陆

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

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

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

public class StpUserUtil {
	
	// 使用匿名子类 重写`stpLogic对象`的一些方法 
	public static StpLogic stpLogic = new StpLogic("user") {
		// 重写 StpLogic 类下的 `splicingKeyTokenName` 函数，返回一个与 `StpUtil` 不同的token名称, 防止冲突 
		@Override
		public String splicingKeyTokenName() {
			return super.splicingKeyTokenName() + "-user";
		}
		// 同理你可以按需重写一些其它方法 ... 
	}; 
	
	// ... 
	
}

再次调用 StpUserUtil.login(10001) 进行登录授权时，token的名称将不再是 satoken，而是我们重写后的 satoken-user。

八、不同体系不同 SaTokenConfig 配置

カスタム StpUserUtil が別の SaTokenConfig オブジェクトを使用する必要がある場合も、非常に簡単です。参考例は次のとおりです。

public class StpUserUtil {
	
	// 使用匿名子类 重写`stpLogic对象`的一些方法 
	public static StpLogic stpLogic = new StpLogic("user") {
		
		// 首先自定义一个 Config 对象 
		SaTokenConfig config = new SaTokenConfig()
			.setTokenName("satoken")
			.setTimeout(2592000)
			// ... 其它set
			;
		
		// 然后重写 stpLogic 配置获取方法 
		@Override
		public SaTokenConfig getConfig() {
			return config;
		}
	};
	
	// ... 
	
}

9、マルチアカウントシステムハイブリッド認証

QQ グループの小規模パートナーは、「マルチアカウント システムでSaInterceptorインターセプタのインターフェイス ログインを認証するにはどうすればよいですか?」と質問しました。

実際、この問題は主にビジネス ニーズによって決まります。例として、バックグラウンド管理者アカウントとフロントエンド ユーザー アカウントを取り上げます。

// 注册 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("/**");
}

---

参考文献

• Sa-Token 文档：sa-token.cc
• Gitee 倉庫のアドレス: gitee.com/dromara/sa-…
• GitHub ウェアハウスのアドレス: github.com/dromara/sa-…