Authentification multi-comptes Sa-Token : fournir des opérations d'authentification pour le compte Admin et le compte Utilisateur du système en même temps

Sa-Token est un framework d'authentification d'autorité Java léger, qui résout principalement une série de problèmes liés à l'autorité tels que l'authentification de connexion, l'authentification d'autorité, l'authentification unique, OAuth2 et l'authentification de passerelle de microservice.

Adresse open source de Gitee : gitee.com/dromara/sa-…

Cet article présentera l'opération d'authentification multi-comptes dans Sa-Token.

1. Analyse de la demande

Parfois, nous concevons deux ensembles de systèmes de compte dans un projet, comme la table d'utilisateurs et la table d'administration d'un système de commerce électronique. Dans ce scénario, si nous utilisons l'API StpUtil pour l'authentification de connexion pour les deux ensembles de comptes, des conflits logiques se produiront inévitablement.

Dans Sa-Token, le modèle de ce problème s'appelle : authentification système multi-comptes.

Pour résoudre ce problème, nous devons disposer d'un mécanisme raisonnable pour séparer l'autorisation de ces deux ensembles de comptes afin qu'ils n'interfèrent pas l'un avec l'autre.

2. Idées d'évolution

Supposons que notre table d'utilisateurs et notre table d'administration aient toutes deux un compte avec id=10001, et que leurs codes de connexion correspondants StpUtil.login(10001)soient les mêmes, alors la question se pose : StpUtil.getLoginId()comment distinguer si l'identifiant de compte obtenu est un utilisateur utilisateur ou un utilisateur administrateur ?

Vous pouvez penser à leur ajouter un préfixe fixe, tel que StpUtil.login("User_" + 10001), StpUtil.login("Admin_" + 10001), qui peut en effet résoudre le problème, mais pareil : vous devez StpUtil.getLoginId()couper le préfixe correspondant pour obtenir le véritable identifiant de compte, de sorte que notre code devienne extrêmement verbeux.

Alors, existe-t-il une solution plus élégante prise en charge au niveau du framework ?

SaManagerOffre la possibilité de créer dynamiquement StpLogic :

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

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

C'est une solution, mais nous devons toujours spécifier le paramètre de type de compte chaque fois que nous appelons la méthode, et le code est un peu long. Ensuite, nous introduisons la deuxième solution : personnaliser la classe de l'outil d'authentification StpUtil.

3. Personnalisez la classe d'outil d'authentification 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 配置

Si le StpUserUtil personnalisé a besoin d'utiliser différents objets SaTokenConfig, c'est aussi très simple, l'exemple de référence est le suivant :

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;
		}
	};
	
	// ... 
	
}

Neuf, authentification hybride de système multi-comptes

SaInterceptorUn petit partenaire du groupe QQ a demandé : Comment authentifier une connexion d'interface dans l'intercepteur sous le système multi-compte ?

En fait, ce problème est principalement déterminé par les besoins de votre entreprise. Prenez le compte administrateur en arrière-plan et le compte utilisateur frontal comme exemples :

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

---

Les références

• Sa-Token 文档：sa-token.cc
• Adresse de l'entrepôt Gitee : gitee.com/dromara/sa-…
• Adresse de l'entrepôt GitHub : github.com/dromara/sa-…