我不想用服务端里基于注解的权限验证框架,比如 Shiro 。所有的服务端 action 接口的权限配置都在后台管理界面进行配置
最简单的 rbac 权限验证,放在 sql 数据库就是 5 个表,用户表,用户角色关联表,角色表,角色菜单关联表,菜单表。而验证就是凭借用户 id 从用户角色表查到关联的 role,在从 role,查到关联的 menu 。一个 sql 语句经过 4 个表。
那么,服务端 rbac 权限验证,是否有必要进行增加性能优化?比如减少权限验证的时间。
我目前就想到一个方式,利用面向对象语言的引用特性,当项目启动时,载入角色与权限的关联数据永驻到服务端内存中,用户登录之后,创建一个集合,然后往集合内添加永驻在内存里的用户所含的角色权限关联引用,并且集合与用户绑定在 session 里。每次权限验证,都将请求 path 和用户的权限引用集合与服务端永驻内存的权限缓存进行对比。不在查询数据库。唯一看得出的缺陷是实时更新角色与 role 对应的维护有点麻烦。除了这个还有其他的方式么?
现在增加了 app 端,app 端用认证的不是 session,还是 token 。这个情况下,app 端的权限验证如果要进行性能优化,那是用什么方式呢,把角色关联数据加密,并到 token 令牌里安全么?还是性能优化没有必要的,直接根据 userid 去调 jdbc,用各 sql 语句一梭子查到菜单表进行对比就行了?
各位搭建编写 web 服务端的时候,权限验证有没有想过性能优化?有的话,一般都是怎样的?
1
cruii 2020-05-26 16:35:42 +08:00
把用户菜单存到 redis 不行么
|
2
rockyou12 2020-05-26 16:45:19 +08:00
首先权限设计不要针对菜单,而要针对资源。不然你多个端(web 、app 等)无法用一套统一的接口与统一的权限框架。
你要是用 jpa,直接都是对象关联,就相当于缓存一个大对象(用户->角色->权限)。我给公司写的框架其实就是这样缓存的。如果要进行更新,不是只更新权限或者角色这层,而是整个大对象全部删掉后重新整个更新。 不过说实话,用户量不大这个缓存作用也不是很大。 而且 app 端哪用优化什么,你登陆了就该拿用户所有权限,然后前端自己比对校验。要是访问到无权限的接口你后端就该直接报错。 |
3
hsluoyz 2020-05-26 16:53:33 +08:00
不要自己搞五张表了,Casbin 直接帮你 handle 三张表:用户角色关联表,角色表,角色菜单关联表,并且性能都是优化好的,支持各种语言、数据库。用户表、菜单表如果字段多,可以自己维护下。你不是专业做权限的,没必要入这个坑,直接用 Casbin 即可: https://casbin.org/
|
6
wshcdr 2020-05-27 11:49:08 +08:00
权限一般都结合缓存的
|