随着前后端分离项目的热潮,前端各大框架的,前后端沟通部分也成了问题,之前服务端渲染的页面生成到前端来,现在前后端可能是两个服务器,一些技术的迁移,本框架的权限部分的设计思想,借鉴了前端大牛的想法,也有传统后端的设计方案,抛砖引玉,做个桥梁,实现前后端分离的权限的设计,代码仅供参考,思路仅供参考,相信优秀的你写自己的代码,用自己的思想会更为贴切,方便。 最终即具有统一响应结构、 前后台数据流转机制(HTTP消息与Java对象的互相转化机制)、统一的异常处理机制、参数验证机制、Cors跨域请求机制以及鉴权机制。
前端设计:采用 Vue 的 element ui ,对于前端设计者来说,应该很好理解源码。
后端设计:shiro + ssm + redis 存储 jwt
交互方式:前端存储jwt,在访问后端时携带,这也是唯一交互验证方式。
前期工作:设计符合需求的vue模板,路由,资源,角色,用户其中对应关系也可从数据表中体现出来。
基本想法就是,用到Vuex 和 Vue Router 前者用来做状态控制,后者绑定路由,这样权限可以直接对应到组件上,某个用于只能访问某个组件,而不用将每个组件都加上权限控制,重要的是还有单点登录。 所以抛砖引玉,写一个通用框架,(至少是通用想法)具体可以模块化来可插拔就ok 了。 非动态路由的问题是只能在拿到权限之后初始化Vue实例,因此必须把登陆页从SPA中剥离出来做成一个独立的页面,用户登录/退出操作需要在两个url之间跳转,体验略差。
另一种做法是直接用所有路由实例化应用,当用户登录拿到权限后再通过元素操作隐藏越权菜单,这时用户还可以手动输入地址访问越权页面,因此还需要给路由加beforeEach钩子来限制路由访问,路由钩子本身会增加一定的性能压力,而且实例化即注册所有路由也会使前端加载冗余的路由组件。 本系统采用的在初始路由注册首页和登录页,并在拿到token后得到权限,然后在实例化Vue实例。路由代码如下:
const router = new Router({ routes: [ { path: '/login', name: "login", component: LoginView, meta: { requiresAuth: false } },{ path: '/index', redirect: '/', meta: { requiresAuth: true } } ] }); generateIndexRouter(); // 验证token,存在才跳转 router.beforeEach((to, from, next) => { let token = sessionStorage.getItem('token') if(to.path === '/') { if(!token) { next({ path: '/login', query: { redirect: to.fullPath } }) return } } if(to.meta.requiresAuth) { if(token) { next() } else { next({ path: '/login', query: { redirect: to.fullPath } }) } } else { next() } }); router.afterEach((to, from) => { // 设置面包屑 let breadCrumbItems = [] let homePageCrumb = { title: '首页', to: '/' } breadCrumbItems.push(homePageCrumb) if(to.meta.nameFullPath) { let fullPathSplit = to.meta.nameFullPath.split('/') fullPathSplit.forEach(( item, index ) => { let routerBreadCrumb = { title: item, to: (index == fullPathSplit.length - 1 ? to.path : '') } breadCrumbItems.push(routerBreadCrumb) }); } // 更新到state router.app.$store.dispatch('setBreadcurmbItems', breadCrumbItems) }) // 生成首页路由 function generateIndexRouter() { if (!sessionStorage.routers) { return } let indexRouter = { path: "/", name: "/", component: resolve => require(['@/views/home/index'], resolve), children: [ ...generateChildRouters() ] } router.addRoutes([indexRouter]) } // 生成嵌套路由(子路由) function generateChildRouters() { let routers = JSON.parse(sessionStorage.routers) let childRouters = [] for(let router of routers) { if(router.code != null) { let routerProps = JSON.parse(router.properties) let childRouter = { path: router.url, name: router.code, component: resolve => require(['@/views/' + router.code + '/index'], resolve), meta: { routerId: router.id, requiresAuth: routerProps.meta.requiresAuth, nameFullPath: routerProps.nameFullPath } } childRouters.push(childRouter) } } return childRouters } export default router;
既然是restful风格,必然有通用返回状态的类,遵循网上开源原则,一类继承hashmap这样达到可以返回任意的数据,通用的数据就是code.msg.data这些,如果有分页会另外加分页,还有一种是,data.msg.state(code).token + 分页类型的数据如:
"data": { "list": null, "pagebar": { "page": 1, "total": 2, "limit": 10 } }, "msg": "error", "state": 0, "is_redirect": true, "redirect_url": "http://qq.com", "token": null
本项目考虑到后期的扩展性,用到了第一类,其中实现了常用的失败和成功的状态码及其响应,类名设计为Result,位于zhcc- common下面,一般性地是封装到ResponseEntity中返回。
分别对应http协议的get/put/post/delete方法,后端权限是:read/:update/:create/:delete
case "get": permissionString += ":read"; break; case "put": permissionString += ":update"; break; case "post": permissionString += ":create"; break; case "delete": permissionString += ":delete";
用的是com.baidu.unbiz.fluentvalidator.ValidationError 而不是hibernateValidator 减轻服务端编程等的压力。直接在controller里面验证,最后封装到Result的fail方法里面返回。
权限的控制主要分为4大类,主要是基于RBAC原理。 路由,资源,角色,用户 路由级别和组件级别可控制
1.权限设计 2.异常设计 3.字典和其他接口设计 4.前后的通讯设计==