集合and-design的Tree组件实现权限管理设置

结合and-design的Tree组件实现权限管理设置

先来介绍一下使用环境：

后端框架：thinkphp 3.2.3

前端：react，并使用and-design作为UI库

数据库：MySQL

再来看一下效果图：



后端的原理可以看我很久前的这篇博客：

thinkphp 3.2.3权限管理

虽然不是完全相同，但是核心其实是一样的，就是设置一个

CommonContrller

让其来继承

Think\Controller

，然后剩余的控制器来继承

CommonController

，在

CommonController

中对控制器和其下的方法进行限制，从而达到控制权限的方法，这种方法从广义上来讲是很容易实现的，难的是如何将这种方法交给用户去设置。

这里再补充一点，一般的后端权限不是垂直的，多个权限之间是有嵌套关系的，比如一个合同管理的权限关系为：

获取合同列表

新增合同

编辑合同

删除合同

后三个权限其实都是依托于第一个第一个权限的，所以当你要给一个用户编辑合同的权限时，一定要给其获取合同列表的权限，这种事情你肯定不能直接要求客户去这么设置，否则体验度立刻下降，用某公司老板的一句话来说就是：

Don’t make me think.

这时刚好找到一个很有意思的组件：Tree组件



这个组件就能很好的解决这个问题上面的问题，并切方便用户进行设置。关于这个组件的具体使用可以看官网的介绍，很简单的。

那么接下来的问题就是如何将这几者联系起来了。

数据库表结构

权限表

字段	数据类型	字段备注
id
pid	int	父id，代表上下级关系
ctrl	varchar	tp控制器
action	varchar	tp控制器下的方法
key	varchar	Tree组件中的key
title	varchar	Tree组件中的title
level	tinyint	Tree组件中的层级

这里可以默认嵌套层级为3层，那么首先筛选出

level

为0的值组成数组，接着是

level

为1的值，按照pid存放到各个对应的数组下，接着是

level

为2的值，依样画葫芦，存放到各个对应的数组下。这样就组成了3维数组。接着要做的就是将这个数组循环放进

Tree

组件中。

角色权限表

字段	数据了类型	字段备注
id
name	varchar	人员名称
auth	varchar	权限列表

例：

id	pid	ctrl	action	key	title	level
1	0	Contract	List	Contract_list	合同管理	0
2	1	Contract	Add	Contract_add	新增合同	1
3	1	Contract	Edit	Cpmtract_edit	编辑合同	1

id	name	auth
1	仓管员	1
2	销售	1,2
3	经理	1,2,3

这样就能实现：仓管员只能查看合同列表，但是无法进行编辑和新增，而销售只能新增但是无法编辑，经理则拥有所有的权限。接着就是根据每一个用户给其设定一个角色就可以了。

前端显示

这里要注意，这里的权限限制不再仅仅是后端限制或者前端限制，而是进行了统一，正是因为这种统一，所以为保证最好的用户体验，前端应保持这样的态度：

无权限时能隐藏就隐藏操作按钮

无法隐藏就disable

无法disable则点击后显示提示信息，如

alert("您无该权限")

这样的体验最好在项目一开始就设置进去，而不是后期添加，要不修改前端代码就很麻烦了。

还有一点，如何在前端维护权限信息，也就是如何在前端保证用户刷新页面后不会出现前端权限设置失效的情况。那就是使用路由重定向，在访问每个路由前先设置一个统一的前置点，在那个前置点从后端权限信息，再统一保存在

Mobx

中，这样每个页面都可以访问到，而且即使用户刷新页面也不会导致缓存消失而前端权限设置消失。

后端宽容

这个是真的，因为上面的权限方案有一个很大的问题，那就是假设一个完整的操作只需要用到一次数据请求，但是实际情况上不是，比如新增合同时，就需要调用一次后端接口，获取客户信息，新增合同的唯一编号，合同类型等信息。然后保存后又要掉用一次后端的接口，将数据保存进数据库，实际上是有两次请求的，但是在上面的情况中，我们只能保存一个接口，这个时候另一个接口做限制时，整个流程就走不通了。

那么如何解决这个问题呢？方案1是设置白名单，当用户访问这些接口时不做权限限制，只需要用户的

session

信息中显示用户是登录状态即可。方案2则是宽容，如果是权限表中未设置的接口，统一开放给用户。我个人的倾向是方案2，因为需求变更实在太快了，如果采用方案1的话，新增加一个接口就需要用户重新更新一下权限表，这是麻烦客户的做法，所以即使方案1更加安全，但是采取方案2更加人性化。

这里再说一个注意点，那就是前端获取数据，这个真的跟一个人的习惯有关，我们公司前端大神喜欢的风格是后端接口尝试型，比如他写合同界面时，需要用到客户信息，他就调用了我写的客户管理界面的后端代码，因为其中有所有的客户信息，但是问题是，这个接口是在权限表中的，当一个用户有新增合同的权限，但是没有客户管理的权限时，新增合同界面的接口就获取不到客户信息，这个时候最快的解决办法就是放开客户管理的权限，让客户能先新增合同。但是这只是缓兵之计，之后还是要改。事情虽小，但是却折射出一个问题，那就是后端接口该怎么写？这里我再重申一遍，根据前端界面写！！！一次请求中就把这个页面所需要的全部数据都传给前端，不要再去调用额外的接口了，否则整个代码即维护困难，各个接口之间也是相互牵制，很难修改。