mall改造：自定义注解和shiro权限结合，解放生产力

好多人私信我，是不是北京疫情严重被隔离了，这里先谢谢大家的关系。是因为最近不是要考核了，都在做考核的事情，也在国家应急部对这次南方的洪涝灾害进行支援。

这次我们聊一聊litemall中的shiro和自定义注解的组合

通过上面的介绍，我们可以得知，litemall本次采用的方式，是没有将前端与按钮的权限一起放到数据库中，而是将前端的页面和权限和按钮权限，通过注解的方式获取。

通过上面两张图我们可以看出，传统的权限表，是会有接口，按钮，页面不通类型的按钮的。但是我们在第二张图上，只看到了shiro格式的后台权限，这里是数据库层次上的不通，当然个人更推荐数据库保存，因为我没有想litemall 作者这样开发过，不知奥会不会有什么不方便的地方，感觉使用作者的方法不是很灵活，优点是不用再去关注前端和按钮权限的。



我们可以看见作者这里采用了自定义注解，我先来解释一下注解：
RetentionPolicy.RUNTIME：注解不仅被保存到class文件中，jvm加载class文件之后，仍然存在
@Target - 标记这个注解应该是哪种 Java 成员,TYPE:用于描述类、接口(包括注解类型) 或enum声明,METHOD:用于描述方法

@RequiresPermissionsDesc(menu = {"商场管理", "品牌管理"}, button = "查询")

menu 菜单，button 按钮，这里的意思说明，前端的那些按钮或页面是可以调用这个接口的。

刚才我们看过数据库，数据库中的数据是 admin:brand:list
但是接口返回的和前端获取到的是 GET /admin/brand/list

说明前端的页面权限不是数据库的而是通过处理过返回的，下面的是代码了的一段debug，我们通过图中看出，通过toApi()方法，将后端的权限，改成了前端Api权限。 前端获取对应的权限进行权限管理。




下面两个截图是权限由 admin:brand:list 到 GET /admin/brand/list 的大体转换流程

通过上面的几个截图，相信大家对我说的shiro+自定义注解有了基本的了解。

了解完了，我们就要开始思考，思考比看一遍或则敲一遍代码有意义。

 

总结梳理：

前端发送请求获取当前用户权限-->

后台shiro进行拦截，查看用户是否登录-->

shiro获取当前用户信息，获取角色及后端接口权限-->

检查缓存中是否已经有当前用户的前端和按钮权限-->

没有通过扫描自定义注解，拿到注解中menu和button的值，进行数据整理-->

整理后的数据和用户的权限校验，返回用户拥有的权限-->

前端拿到权限信息，进行页面显示控制。

 

首先我来总结一下，如果是简单的项目使用litemall的这种权限方式我觉得挺好，简单实用。
但是当项目比较大，或者前端使用的插件都不相同，所以有点时候会经常涉及到权限的改动，比方权限过期的问题，这个时候如果使用这种方法，每一次改动都需要修改代码，在大项目的每一次发版都是严谨的，所以就不是很实用了。

 

看开源项目最重要的目的是学习，然后根据自己的实际清空去选择使用，这里谢谢作者给提供了一个新的思路。

喜欢点下关注，你的关注是我写作的最大支持