mirror of
https://gitee.com/dromara/sa-token.git
synced 2025-04-05 17:37:53 +08:00
v1.26.1 beta
This commit is contained in:
click33
parent
3a4c1ef8f0
commit
9bd367b877
18
.gitee/ISSUE_TEMPLATE.md
Normal file
18
.gitee/ISSUE_TEMPLATE.md
Normal file
@ -0,0 +1,18 @@
|
||||
### 使用版本:
|
||||
请提供一下版本号
|
||||
|
||||
|
||||
### 报错信息：
|
||||
请提供报错的详细信息
|
||||
|
||||
|
||||
### 希望结果：
|
||||
相比于已发生的报错，您希望看到什么样的运行结果
|
||||
|
||||
|
||||
### 复现步骤：
|
||||
如果复现步骤比较复杂，请将 demo 上传到 git 并留下地址
|
||||
|
||||
|
||||
备注：您提供的信息越充足，我们将越能快速的定位错误
|
||||
|
||||
18
.github/ISSUE_TEMPLATE.md
vendored
Normal file
18
.github/ISSUE_TEMPLATE.md
vendored
Normal file
@ -0,0 +1,18 @@
|
||||
### 使用版本:
|
||||
请提供一下版本号
|
||||
|
||||
|
||||
### 报错信息：
|
||||
请提供报错的详细信息
|
||||
|
||||
|
||||
### 希望结果：
|
||||
相比于已发生的报错，您希望看到什么样的运行结果
|
||||
|
||||
|
||||
### 复现步骤：
|
||||
如果复现步骤比较复杂，请将 demo 上传到 git 并留下地址
|
||||
|
||||
|
||||
备注：您提供的信息越充足，我们将越能快速的定位错误
|
||||
|
||||
@ -13,7 +13,7 @@ public class SaTokenConsts {
|
||||
/**
|
||||
* Sa-Token 当前版本号
|
||||
*/
|
||||
public static final String VERSION_NO = "v1.26.0";
|
||||
public static final String VERSION_NO = "v1.26.1";
|
||||
|
||||
/**
|
||||
* Sa-Token 开源地址
|
||||
|
||||
@ -77,6 +77,7 @@
|
||||
- [Session模型详解](/fun/session-model)
|
||||
- [TokenInfo参数详解](/fun/token-info)
|
||||
- [解决反向代理 uri 丢失的问题](/fun/curr-domain)
|
||||
- [参考：把权限放在缓存里](/fun/jur-cache)
|
||||
- [解决跨域问题](/fun/cors-filter)
|
||||
- [框架源码所有技术栈](/fun/tech-stack)
|
||||
- [为Sa-Token贡献代码](/fun/git-pr)
|
||||
|
||||
52
sa-token-doc/doc/fun/jur-cache.md
Normal file
52
sa-token-doc/doc/fun/jur-cache.md
Normal file
@ -0,0 +1,52 @@
|
||||
# 参考：将权限数据放在缓存里
|
||||
前面我们讲解了如何通过`StpInterface`接口注入权限数据，框架默认是不提供缓存能力的，如果你想减小数据库的访问压力，则需要将权限数据放到缓存中
|
||||
|
||||
---
|
||||
|
||||
参考示例：
|
||||
``` java
|
||||
/**
|
||||
* 返回一个账号所拥有的权限码集合
|
||||
*/
|
||||
@Override
|
||||
public List<String> getPermissionList(Object loginId, String loginType) {
|
||||
|
||||
// 1. 获取这个账号所属角色id
|
||||
long roleId = StpUtil.getSessionByLoginId(loginId).get("Role_Id", () -> {
|
||||
return ...; // 从数据库查询这个账号所属的角色id
|
||||
});
|
||||
|
||||
// 2. 获取这个角色id拥有的权限列表
|
||||
SaSession roleSession = SaSessionCustomUtil.getSessionById("role-" + roleId);
|
||||
List<String> list = roleSession.get("Permission_List", () -> {
|
||||
return ...; // 从数据库查询这个角色id拥有的权限列表
|
||||
});
|
||||
|
||||
// 3. 返回
|
||||
return list;
|
||||
}
|
||||
```
|
||||
|
||||
##### 疑问：为什么不直接缓存 `[账号id->权限列表]`的关系，而是 `[账号id -> 角色id -> 权限列表]`？
|
||||
|
||||
<!-- ``` java
|
||||
// 在一个账号登录时写入其权限数据
|
||||
RedisUtil.setValue("账号id", <权限列表>);
|
||||
|
||||
// 然后在`StpInterface`接口中，如下方式获取
|
||||
List<String> list = RedisUtil.getValue("账号id");
|
||||
``` -->
|
||||
|
||||
答：`[账号id->权限列表]`的缓存方式虽然更加直接粗暴，却有一个严重的问题：
|
||||
|
||||
- 通常我们系统的权限架构是RBAC模型：权限与用户没有直接的关系，而是：用户拥有指定的角色，角色再拥有指定的权限
|
||||
- 而这种'拥有关系'是动态的，是可以随时修改的，一旦我们修改了它们的对应关系，便要同步修改或清除对应的缓存数据
|
||||
|
||||
现在假设如下业务场景：我们系统中有十万个账号属于同一个角色，当我们变动这个角色的权限时，难道我们要同时清除这十万个账号的缓存信息吗？
|
||||
这显然是一个不合理的操作，同一时间缓存大量清除容易引起Redis的缓存雪崩
|
||||
|
||||
而当我们采用 `[账号id -> 角色id -> 权限列表]` 的缓存模型时，则只需要清除或修改 `[角色id -> 权限列表]` 一条缓存即可
|
||||
|
||||
一言以蔽之：权限的缓存模型需要跟着权限模型走，角色缓存亦然
|
||||
|
||||
|
||||
@ -144,7 +144,9 @@
|
||||
<script src="https://unpkg.zhimg.com/docsify@4.9.4/lib/docsify.min.js"></script>
|
||||
<script src="https://unpkg.zhimg.com/docsify-copy-code@2.1.0/dist/docsify-copy-code.min.js"></script>
|
||||
<script src="https://unpkg.zhimg.com/prismjs@1.20.0/components/prism-java.min.js"></script>
|
||||
<!-- 搜索框 -->
|
||||
<script src="https://cdn.jsdelivr.net/npm/docsify/lib/plugins/search.min.js"></script>
|
||||
<!-- 多 tab 切换 -->
|
||||
<script src="https://unpkg.zhimg.com/docsify-tabs@1.4.4"></script>
|
||||
<!-- img点击放大 -->
|
||||
<script src="https://cdn.jsdelivr.net/npm/docsify/lib/plugins/zoom-image.min.js"></script>
|
||||
|
||||
@ -84,7 +84,7 @@ public class UserController {
|
||||
|
||||
// 查询登录状态，浏览器访问： http://localhost:8081/user/isLogin
|
||||
@RequestMapping("isLogin")
|
||||
public String isLogin(String username, String password) {
|
||||
public String isLogin() {
|
||||
return "当前会话是否登录：" + StpUtil.isLogin();
|
||||
}
|
||||
|
||||
|
||||
@ -13,7 +13,7 @@ Sa-token默认将数据保存在内存中，此模式读写速度最快，且避
|
||||
|
||||
---
|
||||
|
||||
### 方式A. 使用jdk默认序列化方式 （Sa-Token 整合 Redis）
|
||||
### 方式1. Sa-Token 整合 Redis （使用jdk默认序列化方式）
|
||||
``` xml
|
||||
<!-- Sa-Token 整合 Redis （使用jdk默认序列化方式） -->
|
||||
<dependency>
|
||||
@ -25,7 +25,7 @@ Sa-token默认将数据保存在内存中，此模式读写速度最快，且避
|
||||
优点：兼容性好，缺点：Session序列化后基本不可读，对开发者来讲等同于乱码
|
||||
|
||||
|
||||
### 方式B. 使用jackson序列化方式（Sa-Token 整合 Redis）
|
||||
### 方式2. Sa-Token 整合 Redis（使用jackson序列化方式）
|
||||
``` xml
|
||||
<!-- Sa-Token 整合 Redis （使用jackson序列化方式） -->
|
||||
<dependency>
|
||||
@ -64,8 +64,8 @@ spring:
|
||||
port: 6379
|
||||
# Redis服务器连接密码（默认为空）
|
||||
# password:
|
||||
# 连接超时时间（毫秒）
|
||||
timeout: 1000ms
|
||||
# 连接超时时间
|
||||
timeout: 10s
|
||||
lettuce:
|
||||
pool:
|
||||
# 连接池最大连接数
|
||||
|
||||
@ -163,53 +163,3 @@ StpUtil.hasPermission("index.html"); // false
|
||||
前端的鉴权只是一个辅助功能，对于专业人员这些限制都是可以轻松绕过的，为保证服务器安全，无论前端是否进行了权限校验，后端接口都需要对会话请求再次进行权限校验！
|
||||
|
||||
|
||||
### 将权限数据放在缓存里
|
||||
前面我们讲解了如何通过`StpInterface`接口注入权限数据，框架默认是不提供缓存能力的，如果你想减小数据库的访问压力，则需要将权限数据放到缓存中
|
||||
|
||||
参考示例：
|
||||
``` java
|
||||
/**
|
||||
* 返回一个账号所拥有的权限码集合
|
||||
*/
|
||||
@Override
|
||||
public List<String> getPermissionList(Object loginId, String loginType) {
|
||||
|
||||
// 1. 获取这个账号所属角色id
|
||||
long roleId = StpUtil.getSessionByLoginId(loginId).get("Role_Id", () -> {
|
||||
return ...; // 从数据库查询这个账号所属的角色id
|
||||
});
|
||||
|
||||
// 2. 获取这个角色id拥有的权限列表
|
||||
SaSession roleSession = SaSessionCustomUtil.getSessionById("role-" + roleId);
|
||||
List<String> list = roleSession.get("Permission_List", () -> {
|
||||
return ...; // 从数据库查询这个角色id拥有的权限列表
|
||||
});
|
||||
|
||||
// 3. 返回
|
||||
return list;
|
||||
}
|
||||
```
|
||||
|
||||
##### 疑问：为什么不直接缓存 `[账号id->权限列表]`的关系，而是 `[账号id -> 角色id -> 权限列表]`？
|
||||
|
||||
<!-- ``` java
|
||||
// 在一个账号登录时写入其权限数据
|
||||
RedisUtil.setValue("账号id", <权限列表>);
|
||||
|
||||
// 然后在`StpInterface`接口中，如下方式获取
|
||||
List<String> list = RedisUtil.getValue("账号id");
|
||||
``` -->
|
||||
|
||||
答：`[账号id->权限列表]`的缓存方式虽然更加直接粗暴，却有一个严重的问题：
|
||||
|
||||
- 通常我们系统的权限架构是RBAC模型：权限与用户没有直接的关系，而是：用户拥有指定的角色，角色再拥有指定的权限
|
||||
- 而这种'拥有关系'是动态的，是可以随时修改的，一旦我们修改了它们的对应关系，便要同步修改或清除对应的缓存数据
|
||||
|
||||
现在假设如下业务场景：我们系统中有十万个账号属于同一个角色，当我们变动这个角色的权限时，难道我们要同时清除这十万个账号的缓存信息吗？
|
||||
这显然是一个不合理的操作，同一时间缓存大量清除容易引起Redis的缓存雪崩
|
||||
|
||||
而当我们采用 `[账号id -> 角色id -> 权限列表]` 的缓存模型时，则只需要清除或修改 `[角色id -> 权限列表]` 一条缓存即可
|
||||
|
||||
一言以蔽之：权限的缓存模型需要跟着权限模型走，角色缓存亦然
|
||||
|
||||
|
||||
|
||||
@ -322,8 +322,8 @@
|
||||
<h3>特别鸣谢</h3>
|
||||
<ul class="list-unstyle">
|
||||
<li><a href="https://dromara.org/zh/projects/" target="_blank">Dromara社区</a></li>
|
||||
<li><a href="https://docsify.js.org/#/zh-cn/" target="_blank">docsify</a></li>
|
||||
<li><a href="http://yanzhi21.com" target="_blank">颜值排行榜</a></li>
|
||||
<li><a href="https://gitee.com/Apache-ShenYu/incubator-shenyu" target="_blank">ShenYu 网关</a></li>
|
||||
<li><a href="https://gitee.com/dromara/TLog" target="_blank">TLog 分布式日志</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="ss-box">
|
||||
@ -344,9 +344,9 @@
|
||||
</ul>
|
||||
</div>
|
||||
<div class="ss-box">
|
||||
<h3 class="last" style="text-align: left; float: none; padding-left: 0px;">Dromara公众号</h3>
|
||||
<h3 class="last" style="text-align: left; float: none; padding-left: 0px;">Sa-Token 公众号</h3>
|
||||
<div class="media-img padding-small-top" style="text-align: left;">
|
||||
<img class="dro-qr" src="https://dromara.org/img/qrcode/qrcode_1.png" width="100" height="100" />
|
||||
<img class="dro-qr" src="https://oss.dev33.cn/sa-token/lykj-gzh.jpg" width="100" height="100" />
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user