mirror of
https://gitee.com/dromara/sa-token.git
synced 2025-09-22 20:13:34 +08:00
137 lines
4.9 KiB
Markdown
137 lines
4.9 KiB
Markdown
![]() |
# 账号封禁
|
|||
|
|
|||
|
之前的章节中,我们学习了 踢人下线 和 强制注销 功能,用于清退违规账号。
|
|||
|
|
|||
|
在部分场景下,我们还需要将其 **账号封禁**,以防止其再次登录。
|
|||
|
|
|||
|
---
|
|||
|
|
|||
|
### 1、账号封禁
|
|||
|
|
|||
|
对指定账号进行封禁:
|
|||
|
|
|||
|
``` java
|
|||
|
// 封禁指定账号
|
|||
|
StpUtil.disable(10001, 86400);
|
|||
|
```
|
|||
|
|
|||
|
参数含义:
|
|||
|
- 参数1:要封禁的账号id。
|
|||
|
- 参数2:封禁时间,单位:秒,此为 86400秒 = 1天(此值为 -1 时,代表永久封禁)。
|
|||
|
|
|||
|
|
|||
|
注意点:对于正在登录的账号,将其封禁并不会使它立即掉线,如果我们需要它即刻下线,可采用先踢再封禁的策略,例如:<br>
|
|||
|
``` java
|
|||
|
// 先踢下线
|
|||
|
StpUtil.kickout(10001);
|
|||
|
// 再封禁账号
|
|||
|
StpUtil.disable(10001, 86400);
|
|||
|
```
|
|||
|
|
|||
|
待到下次登录时,我们先校验一下这个账号是否已被封禁:
|
|||
|
``` java
|
|||
|
// 校验指定账号是否已被封禁,如果被封禁则抛出异常 `DisableServiceException`
|
|||
|
StpUtil.checkDisable(10001);
|
|||
|
|
|||
|
// 通过校验后,再进行登录:
|
|||
|
StpUtil.login(10001);
|
|||
|
```
|
|||
|
|
|||
|
!> 旧版本在 `StpUtil.login()` 时会自动校验账号是否被封禁,新版本将 校验封禁 和 登录 两个动作分离成两个方法,不再自动校验,请注意其中的逻辑更改。
|
|||
|
|
|||
|
此模块所有方法:
|
|||
|
``` java
|
|||
|
// 封禁指定账号
|
|||
|
StpUtil.disable(10001, 86400);
|
|||
|
|
|||
|
// 获取指定账号是否已被封禁 (true=已被封禁, false=未被封禁)
|
|||
|
StpUtil.isDisable(10001);
|
|||
|
|
|||
|
// 校验指定账号是否已被封禁,如果被封禁则抛出异常 `DisableServiceException`
|
|||
|
StpUtil.checkDisable(10001);
|
|||
|
|
|||
|
// 获取指定账号剩余封禁时间,单位:秒,如果该账号未被封禁,则返回-2
|
|||
|
StpUtil.getDisableTime(10001);
|
|||
|
|
|||
|
// 解除封禁
|
|||
|
StpUtil.untieDisable(10001);
|
|||
|
```
|
|||
|
|
|||
|
|
|||
|
### 2、分类封禁
|
|||
|
|
|||
|
有的时候,我们并不需要将整个账号禁掉,而是只禁止其访问部分服务。
|
|||
|
|
|||
|
假设我们在开发一个电商系统,对于违规账号的处罚,我们设定三种分类封禁:
|
|||
|
|
|||
|
- 1、封禁评价能力:账号A 因为多次虚假好评,被限制订单评价功能。
|
|||
|
- 2、封禁下单能力:账号B 因为多次薅羊毛,被限制下单功能。
|
|||
|
- 3、封禁开店能力:账号C 因为店铺销售假货,被限制开店功能。
|
|||
|
|
|||
|
相比于封禁账号的一刀切处罚,这里的关键点在于:每一项能力封禁的同时,都不会对其它能力造成影响。
|
|||
|
|
|||
|
也就是说我们需要一种只对部分服务进行限制的能力,对应到代码层面,就是只禁止部分接口的调用。
|
|||
|
|
|||
|
``` java
|
|||
|
// 封禁指定用户评论能力,期限为 1天
|
|||
|
StpUtil.disable(10001, "comment", 86400);
|
|||
|
|
|||
|
// 在评论接口,校验一下,会抛出异常:`DisableServiceException`,使用 e.getService() 可获取业务标识 `comment`
|
|||
|
StpUtil.checkDisable(10001, "comment");
|
|||
|
|
|||
|
// 在下单时,我们校验一下 下单能力,并不会抛出异常,因为我们没有限制其下单功能
|
|||
|
StpUtil.checkDisable(10001, "place-order");
|
|||
|
|
|||
|
// 现在我们再将其下单能力封禁一下,期限为 7天
|
|||
|
StpUtil.disable(10001, "place-order", 86400 * 7);
|
|||
|
|
|||
|
// 然后在下单接口,我们添加上校验代码,此时用户便为因为下单能力被封禁而无法下单(代码抛出异常)
|
|||
|
StpUtil.checkDisable(10001, "place-order");
|
|||
|
|
|||
|
// 但是此时,用户如果调用开店功能的话,还是可以通过,因为我们没有限制其开店能力 (除非我们再调用了封禁开店的代码)
|
|||
|
StpUtil.checkDisable(10001, "open-shop");
|
|||
|
```
|
|||
|
|
|||
|
通过以上示例,你应该大致可以理解 `业务封禁 -> 业务校验` 的处理步骤。
|
|||
|
|
|||
|
有关分类封禁的所有方法:
|
|||
|
``` java
|
|||
|
// 封禁 指定账号 指定服务
|
|||
|
StpUtil.disable(10001, "comment", 86400);
|
|||
|
|
|||
|
// 指定账号 指定服务 是否已被封禁 (true=已被封禁, false=未被封禁)
|
|||
|
StpUtil.isDisable(10001, "comment");
|
|||
|
|
|||
|
// 校验 指定账号 指定服务 是否已被封禁,如果被封禁则抛出异常 `DisableServiceException`
|
|||
|
StpUtil.checkDisable(10001, "comment");
|
|||
|
|
|||
|
// 获取 指定账号 指定服务 剩余封禁时间,单位:秒(-1=永久封禁,-2=未被封禁)
|
|||
|
StpUtil.getDisableTime(10001, "comment");
|
|||
|
|
|||
|
// 解封指定账号、指定服务
|
|||
|
StpUtil.untieDisable(10001, "comment");
|
|||
|
```
|
|||
|
|
|||
|
### 3、使用注解完成封禁校验
|
|||
|
首先我们需要注册 Sa-Token 全局拦截器(可参考 [注解鉴权](/use/at-check) 章节),然后我们就可以使用以下注解校验账号是否封禁
|
|||
|
|
|||
|
``` java
|
|||
|
// 校验当前账号是否被封禁 comment 服务,如果已被封禁会抛出异常,无法进入方法
|
|||
|
@SaCheckDisable("comment")
|
|||
|
@PostMapping("send")
|
|||
|
public SaResult send() {
|
|||
|
// ...
|
|||
|
return SaResult.ok();
|
|||
|
}
|
|||
|
|
|||
|
// 校验当前账号是否被封禁 comment、place-order、open-shop 等服务,指定多个值,只要有一个已被封禁,就无法进入方法
|
|||
|
@SaCheckDisable({"comment", "place-order", "open-shop"})
|
|||
|
@PostMapping("send")
|
|||
|
public SaResult send() {
|
|||
|
// ...
|
|||
|
return SaResult.ok();
|
|||
|
}
|
|||
|
```
|
|||
|
|
|||
|
|