服务端 rbac 权限验证,是否有必要进行增加性能优化?
我不想用服务端里基于注解的权限验证框架,比如 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 服务端的时候,权限验证有没有想过性能优化?有的话,一般都是怎样的?