Shiro 的漏洞已爆出很多年, 我们只关心到了它如何触发, 有时并没有想过这个框架是干嘛的, 甚至没有分析过该框架的底层运行逻辑, 那么本篇文章, 让大家从开发者的角度, 来观察。
概念
为了实现不同身份登录系统, 出现的功能模块不一样。这个需求叫做权限管理。
学生登录后, 出现的功能模块为: 选课, 成绩查询, 课程表
老师登陆后, 出现的功能模块为: 学生管理, 成绩录入
那么有了这个基础的概念之后, 我们再看一个比较复杂的权限管理案例:
具体实现
第一种方式
这种方式适用于权限管理比较单一, 用户少, 每类用户权限固定的场景. 根据不同的页面来实现功能不一致的情况.
这种方式的缺点则是, 假设需要在销售人员主页增加新的功能时, 我们需要修改index1.html页面内容, 增加上新的功能, 需要后期慢慢维护.
这种基于页面的开发, 是不建议的.
第二种方式
这一种设计是RBAC (基于角色的访问控制)的基本原型, 也不是最终版本, 看起来已经实现动态的显示功能效果了. 但是这里会存在一个问题.
假设我们新增了一个Heihu577用户, 那么我们就需要在用户权限表中增加很多权限, 那么假设Heihu577用户所需要的权限与liucheng用户权限一致, 那么用户权限表中又需要给Heihu577用户分配很多权限id, 直到与用户liucheng的权限id是一致的, 这样大大减少了灵活性.
那么这里我们需要引入角色的概念,角色是什么？我们不妨看下图进行理解.
现在的权限分配, 是根据角色的, 我们只需要指明某个用户是某个角色, 即可得到该角色的具体权限. 而这么做的弊端则是, 假设A & B用户是同一角色, 而我们希望某一功能只给A用户而不给B用户, 这个时候怎么办呢？
我们只需要增加一个用户权限表, 将额外的权限分配给具体用户即可, 当然随着业务逻辑的复杂, 我们的表也跟着复杂化了. 那么除了表结构的设计, 还需要我们程序设计的思想:
而这里过滤器/拦截器部分我们也可以自己写流程, 判断当前是否是登录状态, 是否有SESSION等. 当我们考虑不全面时程序也可能出现BUG.
而这种情况我们也可以选择使用安全框架, 帮助我们在应用系统开发过程完成认证以及授权的工作. 而安全框架类似于一个保安的角色:
这是一个演唱会的案例, 根据你的门票类别, 到达具体的座位, 当然这一切都需要你去告诉这个保安如何匹配规则, 换到程序里, 我们也仅仅做一个配置即可. 而这里我们就可以选择使用 Shiro, Shiro 就做了这些事情, 类似于 Shiro 的框架还有很多, Spring Security, OAuth2等.
