From 9bd367b8774b69c1ac07170bee1c195cd61935ac Mon Sep 17 00:00:00 2001 From: click33 <2393584716@qq.com> Date: Thu, 9 Sep 2021 02:37:40 +0800 Subject: [PATCH] v1.26.1 beta --- .gitee/ISSUE_TEMPLATE.md | 18 +++++++ .github/ISSUE_TEMPLATE.md | 18 +++++++ .../cn/dev33/satoken/util/SaTokenConsts.java | 2 +- sa-token-doc/doc/_sidebar.md | 1 + sa-token-doc/doc/fun/jur-cache.md | 52 +++++++++++++++++++ sa-token-doc/doc/index.html | 2 + sa-token-doc/doc/start/example.md | 2 +- sa-token-doc/doc/up/integ-redis.md | 8 +-- sa-token-doc/doc/use/jur-auth.md | 50 ------------------ sa-token-doc/index.html | 8 +-- 10 files changed, 101 insertions(+), 60 deletions(-) create mode 100644 .gitee/ISSUE_TEMPLATE.md create mode 100644 .github/ISSUE_TEMPLATE.md create mode 100644 sa-token-doc/doc/fun/jur-cache.md diff --git a/.gitee/ISSUE_TEMPLATE.md b/.gitee/ISSUE_TEMPLATE.md new file mode 100644 index 00000000..5f14499d --- /dev/null +++ b/.gitee/ISSUE_TEMPLATE.md @@ -0,0 +1,18 @@ +### 使用版本: +请提供一下版本号 + + +### 报错信息： +请提供报错的详细信息 + + +### 希望结果： +相比于已发生的报错，您希望看到什么样的运行结果 + + +### 复现步骤： +如果复现步骤比较复杂，请将 demo 上传到 git 并留下地址 + + +备注：您提供的信息越充足，我们将越能快速的定位错误 + diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md new file mode 100644 index 00000000..5f14499d --- /dev/null +++ b/.github/ISSUE_TEMPLATE.md @@ -0,0 +1,18 @@ +### 使用版本: +请提供一下版本号 + + +### 报错信息： +请提供报错的详细信息 + + +### 希望结果： +相比于已发生的报错，您希望看到什么样的运行结果 + + +### 复现步骤： +如果复现步骤比较复杂，请将 demo 上传到 git 并留下地址 + + +备注：您提供的信息越充足，我们将越能快速的定位错误 + diff --git a/sa-token-core/src/main/java/cn/dev33/satoken/util/SaTokenConsts.java b/sa-token-core/src/main/java/cn/dev33/satoken/util/SaTokenConsts.java index 11564126..7e6bc9a5 100644 --- a/sa-token-core/src/main/java/cn/dev33/satoken/util/SaTokenConsts.java +++ b/sa-token-core/src/main/java/cn/dev33/satoken/util/SaTokenConsts.java @@ -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 开源地址 diff --git a/sa-token-doc/doc/_sidebar.md b/sa-token-doc/doc/_sidebar.md index 3f214e00..b966bb3a 100644 --- a/sa-token-doc/doc/_sidebar.md +++ b/sa-token-doc/doc/_sidebar.md @@ -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) diff --git a/sa-token-doc/doc/fun/jur-cache.md b/sa-token-doc/doc/fun/jur-cache.md new file mode 100644 index 00000000..ada57ee1 --- /dev/null +++ b/sa-token-doc/doc/fun/jur-cache.md @@ -0,0 +1,52 @@ +# 参考：将权限数据放在缓存里 +前面我们讲解了如何通过`StpInterface`接口注入权限数据，框架默认是不提供缓存能力的，如果你想减小数据库的访问压力，则需要将权限数据放到缓存中 + +--- + +参考示例： +``` java +/** + * 返回一个账号所拥有的权限码集合 + */ +@Override +public List 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 list = roleSession.get("Permission_List", () -> { + return ...; // 从数据库查询这个角色id拥有的权限列表 + }); + + // 3. 返回 + return list; +} +``` + +##### 疑问：为什么不直接缓存 `[账号id->权限列表]`的关系，而是 `[账号id -> 角色id -> 权限列表]`？ + + + +答：`[账号id->权限列表]`的缓存方式虽然更加直接粗暴，却有一个严重的问题： + +- 通常我们系统的权限架构是RBAC模型：权限与用户没有直接的关系，而是：用户拥有指定的角色，角色再拥有指定的权限 +- 而这种'拥有关系'是动态的，是可以随时修改的，一旦我们修改了它们的对应关系，便要同步修改或清除对应的缓存数据 + +现在假设如下业务场景：我们系统中有十万个账号属于同一个角色，当我们变动这个角色的权限时，难道我们要同时清除这十万个账号的缓存信息吗？ +这显然是一个不合理的操作，同一时间缓存大量清除容易引起Redis的缓存雪崩 + +而当我们采用 `[账号id -> 角色id -> 权限列表]` 的缓存模型时，则只需要清除或修改 `[角色id -> 权限列表]` 一条缓存即可 + +一言以蔽之：权限的缓存模型需要跟着权限模型走，角色缓存亦然 + + diff --git a/sa-token-doc/doc/index.html b/sa-token-doc/doc/index.html index 694d63a1..65bb3db6 100644 --- a/sa-token-doc/doc/index.html +++ b/sa-token-doc/doc/index.html @@ -144,7 +144,9 @@ + + diff --git a/sa-token-doc/doc/start/example.md b/sa-token-doc/doc/start/example.md index 602d282f..3a5610da 100644 --- a/sa-token-doc/doc/start/example.md +++ b/sa-token-doc/doc/start/example.md @@ -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(); } diff --git a/sa-token-doc/doc/up/integ-redis.md b/sa-token-doc/doc/up/integ-redis.md index 29ad40bd..4c9cf408 100644 --- a/sa-token-doc/doc/up/integ-redis.md +++ b/sa-token-doc/doc/up/integ-redis.md @@ -13,7 +13,7 @@ Sa-token默认将数据保存在内存中，此模式读写速度最快，且避 --- -### 方式A. 使用jdk默认序列化方式 （Sa-Token 整合 Redis） +### 方式1. Sa-Token 整合 Redis （使用jdk默认序列化方式） ``` xml @@ -25,7 +25,7 @@ Sa-token默认将数据保存在内存中，此模式读写速度最快，且避 优点：兼容性好，缺点：Session序列化后基本不可读，对开发者来讲等同于乱码 -### 方式B. 使用jackson序列化方式（Sa-Token 整合 Redis） +### 方式2. Sa-Token 整合 Redis（使用jackson序列化方式） ``` xml @@ -64,8 +64,8 @@ spring: port: 6379 # Redis服务器连接密码（默认为空） # password: - # 连接超时时间（毫秒） - timeout: 1000ms + # 连接超时时间 + timeout: 10s lettuce: pool: # 连接池最大连接数 diff --git a/sa-token-doc/doc/use/jur-auth.md b/sa-token-doc/doc/use/jur-auth.md index adfed869..14f39365 100644 --- a/sa-token-doc/doc/use/jur-auth.md +++ b/sa-token-doc/doc/use/jur-auth.md @@ -163,53 +163,3 @@ StpUtil.hasPermission("index.html"); // false 前端的鉴权只是一个辅助功能，对于专业人员这些限制都是可以轻松绕过的，为保证服务器安全，无论前端是否进行了权限校验，后端接口都需要对会话请求再次进行权限校验！ -### 将权限数据放在缓存里 -前面我们讲解了如何通过`StpInterface`接口注入权限数据，框架默认是不提供缓存能力的，如果你想减小数据库的访问压力，则需要将权限数据放到缓存中 - -参考示例： -``` java -/** - * 返回一个账号所拥有的权限码集合 - */ -@Override -public List 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 list = roleSession.get("Permission_List", () -> { - return ...; // 从数据库查询这个角色id拥有的权限列表 - }); - - // 3. 返回 - return list; -} -``` - -##### 疑问：为什么不直接缓存 `[账号id->权限列表]`的关系，而是 `[账号id -> 角色id -> 权限列表]`？ - - - -答：`[账号id->权限列表]`的缓存方式虽然更加直接粗暴，却有一个严重的问题： - -- 通常我们系统的权限架构是RBAC模型：权限与用户没有直接的关系，而是：用户拥有指定的角色，角色再拥有指定的权限 -- 而这种'拥有关系'是动态的，是可以随时修改的，一旦我们修改了它们的对应关系，便要同步修改或清除对应的缓存数据 - -现在假设如下业务场景：我们系统中有十万个账号属于同一个角色，当我们变动这个角色的权限时，难道我们要同时清除这十万个账号的缓存信息吗？ -这显然是一个不合理的操作，同一时间缓存大量清除容易引起Redis的缓存雪崩 - -而当我们采用 `[账号id -> 角色id -> 权限列表]` 的缓存模型时，则只需要清除或修改 `[角色id -> 权限列表]` 一条缓存即可 - -一言以蔽之：权限的缓存模型需要跟着权限模型走，角色缓存亦然 - - diff --git a/sa-token-doc/index.html b/sa-token-doc/index.html index e9fde33b..12e5fa4d 100644 --- a/sa-token-doc/index.html +++ b/sa-token-doc/index.html @@ -322,8 +322,8 @@

特别鸣谢

@@ -344,9 +344,9 @@
-

Dromara公众号

+

Sa-Token 公众号

- +