基于vue(element ui) + ssm + shiro 的权限框架。
领悟，理解，消化它！

引言

心声

现在的Java世界，各种资源很丰富，不得不说，从分布式，服务化，orm,再到前端控制，权限等等玲琅满目，网上有句话说，语言框架迭代太快了，我学不动了，不如回去搬砖吧，可是天这么热，砖烫手啊。程序搞起来很容易，就是有点头冷。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Mui40l9m-1603114221264)(http://hoult-blog.oss-cn-beijing.aliyuncs.com/image-1603113328822.png)]

程序员的两大世界难题

重复轮子

语言框架迭代太快，没错，就简单来说高级语言就有几十种，虽然流行的就那么几种，语言就是重复之一，从语言想表达的作用上来看，都是为了操作计算机，我想未来计算机语言的前景可能是语言一体化，当然，这是个很漫长的路，相信一些语言的创造者，当初也是对某语言不满意，然后就去改造，但是其实绝大部分还是重复的，这一方面，我深有体会，当初，仅仅为了更好地学习MVC框架原理，觉得最好的学习就是重写它，最后，比如hulichao_framework下面的oliver就是结果的残品，只是实现了基本的从页面到处理端的映射，以及处理返回，其实想想也比较简单，尤其是原理，就是页面与控制器更好地处理与映射，当然完美重写，我没有这样干，现在流行的开源mvc框架已经很多了，另外一个就是简单重构过orm框架hulichao_framework下面的yBatis，实现了什么呢，就是数据库与Java程序之间的相互映射，同时约定固定方法开头的可以不需要写sql语句，想说明什么问题呢，其一，我在重复造轮子，当然在这个学习的过程中，我还是收获蛮大的，即使现有框架不能满足部分功能，但是重新改造它代价如果比较高，也不建议，其二，学习的过程就是先原理，再接口，再注释代码的过程，就像前面的框架从一开始，我想实现的主要功能明白了，然后参考主要的原理，设计接口，最后写代码实现，岂有难载。

沟通问题

第二个问题其实不仅涉及到人与人，也涉及到了机器与人的关系，产品经理说，我想做一台挖掘机来炒菜，挖掘机根据最好的优化路线行驶，就跟现在的无人车一样，同时设备齐全，能根据主人的口味推荐出菜系，这样既可以保持其原有功用，又可以作为私家小助手，用最优雅的方式做出最美味的菜，不就是炒菜么，对于很多人来说也不复杂，开个挖掘机相信也不需要太多知识，还有做推荐算法的，请一些相关领域专家，应该也不是很大问题，但是整个流程组合起来就比较费劲了，互联网就是这样，把生活中各种各种实实在在的问题用互联网的思维来实现，那么有什么问题呢，那就是沟通，各个专业人员之间的沟通，设计者的想法与实现者的想法的互动，机器与人的互动。听起来这是个段子，或者科幻电影的情节，嗯，其实确实是。对于程序员，与同事的沟通，与产品经理沟通，需求是什么，能实现成怎么样，就是看整个团队的契合度吧。

建议

理解原理有用，但不要重复造轮子，不要重复造轮子，不要重复造轮子,宁愿去github找一圈找到基本合适的轮子改造，也不要为了装逼写自己轮子，否则会很难受，至于沟通，不得不说就是个难解，所以出来了面向接口设计，面向接口编程，这样的方式比肥仔快乐水更自然。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zas50pIt-1603114132736)(http://hoult-blog.oss-cn-beijing.aliyuncs.com/image-1603113460553.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-K71KBnUk-1603114132738)(http://hoult-blog.oss-cn-beijing.aliyuncs.com/image-1603113486166.png)]

正题

随着前后端分离项目的热潮，前端各大框架的，前后端沟通部分也成了问题，之前服务端渲染的页面生成到前端来，现在前后端可能是两个服务器，一些技术的迁移，本框架的权限部分的设计思想，借鉴了前端大牛的想法，也有传统后端的设计方案，抛砖引玉，做个桥梁，实现前后端分离的权限的设计，代码仅供参考，思路仅供参考，相信优秀的你写自己的代码，用自己的思想会更为贴切，方便。
最终即具有统一响应结构、 前后台数据流转机制(HTTP消息与Java对象的互相转化机制)、统一的异常处理机制、参数验证机制、Cors跨域请求机制以及鉴权机制
前端设计：采用Vue的element ui ，对于前端设计者来说，应该很好理解源码。
后端设计：shiro + ssm + redis存储jwt
交互方式：前端存储jwt，在访问后端时携带，这也是唯一交互验证方式。
前期工作：设计符合需求的vue模板，路由，资源，角色，用户其中对应关系也可从数据表中体现出来

写在前

实际的应用中，其一是要求用户简单地进行注册登录，其二是对其授权，附带的有session管理和加密，所以诞生了shiro这款框架，而前后端分离的趋势，使得shiro更好地应用于前端更有实际意义，而目前像vue类似的前端框架也很热门，同时正好接触到了vue，所以为了适应要求，抽象出来基于前后端完全分离的权限框架。
另外，一般认为权限只能是后端来做，但是前后端分离的情况下呢？这样岂不是很没有意义。况且关于vue的权限控制在业界相对没有主流的方案，百度一下，这方面的资料也不多，基本都很零散。
前端地址：https://github.com/hulichao/zhcc-view-source.git
后端地址：https://github.com/hulichao/zhcc-server.git

设计思路

基本想法就是，用到Vuex 和 Vue Router 前者用来做状态控制，后者绑定路由，这样权限可以直接对应到组件上，某个用于只能访问某个组件，而不用将每个组件都加上权限控制，重要的是还有单点登录。
所以抛砖引玉，写一个通用框架，（至少是通用想法）具体可以模块化来可插拔就ok 了。
非动态路由的问题是只能在拿到权限之后初始化Vue实例，因此必须把登陆页从SPA中剥离出来做成一个独立的页面，用户登录/退出操作需要在两个url之间跳转，体验略差。

另一种做法是直接用所有路由实例化应用，当用户登录拿到权限后再通过元素操作隐藏越权菜单，这时用户还可以手动输入地址访问越权页面，因此还需要给路由加beforeEach钩子来限制路由访问，路由钩子本身会增加一定的性能压力，而且实例化即注册所有路由也会使前端加载冗余的路由组件。
本系统采用的在初始路由注册首页和登录页，并在拿到token后得到权限，然后在实例化Vue实例。路由代码如下：

const router = new Router({
   
  routes