前后端分离后的权限控制设计方案

vlambda
2020-04-21

前后端分离后的权限控制设计方案

近几年随着react、angular、vue等前端框架兴起，前后端分离的架构迅速流行。但同时权限控制也带来了问题。

网上很多前、后端分离权限仅仅都仅仅在描述前端权限控制、且是较简单、固定的角色场景，满足不了我们用户、角色都是动态的场景。

且仅仅前端进行权限控制并不是真正意义的权限控制，它只是减少页面结构暴露、增强用户体验的功效。

场景

系统为后台管理系统，包含了用户创建、用户登录、用户管理自己的资源。用户经常会新增、删除，也可以根据工作情况随时调整页面、功能权限，所以采用用户-角色-页面权限方案实现。

为什么不行：

根据前端路由表显示左侧菜单，但vue-router的路由表主要为了组织代码，经常我们所需要的菜单并非一致。比如某个前端路由a子路由有b、c，但菜单中我们想要直接一级菜单就显示b、c或者将b、c各放到其他菜单下。所以这种非常不灵活。
一个路由是菜单还是页面？是否需要显示到菜单中？是否验证权限？哪个角色或者用户拥有权限？这些都需要写到前端路由里面，一旦有任何权限变动就要大量调整代码。
如果权限写死在前端，那么角色或者用户必须已知且固定不变。比如页面1的meta增加属性标识可访问的角色为a和b

页面

一个页面即一个前端页面，比如首页、用户管理页、资源管理页等。

基本思路为：前端路由保持不变，数据库存储菜单结构、页面权限控制（可以直接做成一个页面来方便管理）等，前端根据数据库中的菜单结构和权限信息来渲染一个菜单出来并只显示其有权限的菜单，并在路由守卫中进行权限控制防止手动输入path越权打开页面。

前端路由（vue-router）中需要正常创建页面及路由。
数据库存储菜单结构和页面权限信息，

菜单（目录、非内容页）可以自己创建，不必要求前端路由中有，因为这是指菜单的可视化的组织结构
页面（内容页）必须是前端路由中已有页面，因为这是用户需要访问的内容。
菜单和页面组成上下级关系，一级可以是菜单也可以是内容页，内容页也可以放在菜单下，这样理论（需要页面菜单样式支持）可以组成无限级菜单
菜单和页面的基本属性包括title（对应路由title）、name（对应路由name）、path（对应路由path）、父级、类型（菜单/页面）、是否可见（左侧菜单栏是否显示：部分页面可能是页面内的链接进去）、是否需要验证权限（部分页面比如首页无需验证权限大家都可以进入）
不需要控制权限且不需要显示到左侧菜单的路由这里可以不进行管理，比如404页面等

前台打开后获取获取数据库的所有菜单、页面及结构，根据是否登录、是否需要验证权限等进行控制，或无权限跳转至登录页
用户登录成功后，再获取用户对应的的页面权限列表，使用上一步获得的所有页面、结构和用户拥有权限的列表渲染出一个菜单，只包含此用户拥有权限的，提升用户体检，避免显示大量用户不能访问的菜单影响使用和不必要的功能暴露。
路由守卫中根据上一步获得的权限列表判断每个跳转，无权限可返回404或无权限页面，防止用户手动输入path越权访问

页面管理：

功能

部分功能有事需要单独控制权限，比如用户管理页面可能允许多个角色查看，但是其中的“创建用户”功能只允许某一个角色使用，那么仅仅使用页面权限是不够。所以需要细粒度的功能权限控制。

网上的方案都是说：根据资源控制增、删、改、查等等，比如针对用户就是用户的创建、修改、删除、查询等。但是在我的实际使用中发现并不切合实际，最起码对像我这种管理后台，资源并不单纯的增删改查，可能有其他地方的其他操作中也会对此用户资源造成影响，比如禁用、删除角色也要禁用、删除用户，那么这个权限到底属于角色的权限还是属于用户的权限，或者后台又改了，角色又影响了其他资源或者不再对用户进行操作，都会影响权限控制。

所以更合理的方法应该为将每个功能单独进行控制并和页面进行关联，且不限定必须是增、删、改、查四种，可以任意定制，只需要与前后端开发约定一个唯一的标识即可。

如上的例子中，用户管理页面下有用户各种功能，角色管理页面中也有个角色禁用、删除功能，可以分别定义标识为role_disable、role_delete，如果拥有role_delete权限即可，即使没有user_delete权限，也可以直接删除用户，否则就不要给其role_delete权限。

用户登录后，从数据库获取其所拥有的的权限列表并存入vuex，包含页面和功能对应关系，例如页面name为user： {user: ['user_delete', 'user_query']}，页面中根据删除按钮可以v-if="hasPermission('user_delete')"判断即可。

页面功能管理：