Autenticación de múltiples cuentas Sa-Token: proporcione operaciones de autenticación para la cuenta de administrador y la cuenta de usuario del sistema al mismo tiempo

Sa-Token es un marco ligero de autenticación de autoridad de Java, que resuelve principalmente una serie de problemas relacionados con la autoridad, como autenticación de inicio de sesión, autenticación de autoridad, inicio de sesión único, OAuth2 y autenticación de puerta de enlace de microservicio.

Dirección de código abierto de Gitee: gitee.com/dromara/sa-…

Este artículo presentará la operación de autenticación de múltiples cuentas en Sa-Token.

1. Análisis de la demanda

A veces, diseñamos dos conjuntos de sistemas de cuentas en un proyecto, como la tabla de usuario y la tabla de administración de un sistema de comercio electrónico. En este escenario, si usamos la API StpUtil para la autenticación de inicio de sesión para ambos conjuntos de cuentas, inevitablemente se producirán conflictos lógicos.

En Sa-Token, el modelo de este problema se denomina: autenticación del sistema multicuenta.

Para resolver este problema, debemos tener un mecanismo razonable para separar la autorización de estos dos conjuntos de cuentas para que no interfieran entre sí.

2. Ideas de evolución

Supongamos que nuestra tabla de usuario y nuestra tabla de administración tienen una cuenta con id = 10001, y sus códigos de inicio de sesión correspondientes StpUtil.login(10001)son los mismos, entonces surge la pregunta: ¿ StpUtil.getLoginId()cómo distinguir si la identificación de cuenta obtenida es un usuario usuario o un usuario administrador?

Puede pensar en agregarles un prefijo fijo, como StpUtil.login("User_" + 10001), StpUtil.login("Admin_" + 10001), que de hecho puede resolver el problema, pero lo mismo: debe StpUtil.getLoginId()eliminar el prefijo correspondiente para obtener la identificación de la cuenta real, de modo que nuestro código se vuelva extremadamente detallado.

Entonces, ¿hay una solución más elegante compatible con el nivel de marco?

SaManagerProporciona la capacidad de crear StpLogic dinámicamente:

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

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

Esta es una solución, pero aún necesitamos especificar el parámetro de tipo de cuenta cada vez que llamamos al método, y el código es un poco largo. A continuación, presentamos la segunda solución: personalizar la clase de herramienta de autenticación StpUtil.

3. Personalice la clase de herramienta de autenticación 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 el StpUserUtil personalizado necesita usar diferentes objetos SaTokenConfig, también es muy simple, el ejemplo de referencia es el siguiente:

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

Nueve, autenticación híbrida del sistema multicuenta

SaInterceptorUn pequeño socio en el grupo QQ preguntó: ¿Cómo autenticar un inicio de sesión de interfaz en el interceptor bajo el sistema de cuentas múltiples ?

De hecho, este problema está determinado principalmente por las necesidades de su negocio.Tome la cuenta de administrador en segundo plano y la cuenta de usuario de front-end como ejemplos:

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

---

Referencias

• Sa-Token 文档：sa-token.cc
• Dirección del almacén de Gitee: gitee.com/dromara/sa-…
• Dirección del almacén de GitHub: github.com/dromara/sa-…