【实测】django测试平台的各种权限管理设计解决方案！超干货！

实测系列都是作者精心打造的单独解决方案文章，及其干货，请注意提前准备饮料，以免噎到...最后别忘了保存和分享。

之前在培训内容中没有学到另外几种的小宝宝们，可以在这里也一起看看咯....对于任何p7以下同学，看完此篇文章，你的实力都会瞬间上升一大步哦~

方案一：隐藏菜单入口法

【后端控制动态数据办法】:

首先菜单模板/组件内的数据要全部使用动态传输，数据由某自动运行接口控制，接口的视图层函数中，先通过request.user.id来判断该用户可看到哪些菜单条目，然后返回即可。

具体判断方案有俩种，一是以菜单为主体，制作菜单权限表，对每个菜单数据增加拥有用户字段。二是以用户为主体，在用户表中，增加所拥有的菜单权限字段。

前者线上维护的时候是以菜单列表页面中增删人员。后者在线维护时候是在个人权限设置页中勾选增删菜单条目。

【后端控制菜单权限办法】：

判断规则逻辑基本一样，主要是菜单的条目是写死在菜单组件/模板中的。而后端传输过来的是各个条目对该用户是否显示的布尔变量(真/假)。

django渲染的传统模板中，可以通过对菜单条目的具体css属性来控制，为style="display:none或者block"

vue-cli前后端分离的菜单组件中，可以通过菜单条目dom层元素的指令 v-if 的真假来控制，数据放在vue实例的data中即可。

方案二：函数层判定函数控制法

【函数层调用式方案】

增加权限列表的增删改查，然后对每个权限都设计可使用的用户。

然后在视图层，对views.py中需要管控的普通函数，都在一开始调用一个权限判定函数，并传入想要关联的权限id和当前登录的用户id。

然后由该判定函数去数据库中匹配到目标权限，再检查用户id是否存在于该权限的用户字段中，若在则返回真，否则返回假。

然后具体函数再根据真假结果，来决定是否继续执行函数还是直接返回"无权限"

【函数层装饰器方案】

和上面方案的区别在于普通函数不是通过调用判定函数来进行判断，而是通过装饰器的方式，把判定权限函数作为装饰器装饰。并传入request请求等参数。

判定函数作为装饰器后，内部判断是否符合权限，如果判断有权限，则直接执行普通函数，否则引发报错或者警告或者返回"无权限"都可。

其他部分设计和上面方案相同。

方案三：接口层统一拦截法

【通过url中的路径部分控制】

此方案可以脱离代码修改和重新部署的麻烦，完全在线维护，甚至在线增删权限。不过同样也要创造权限数据表，并且在线实现增删改查，权限数据需要有'关联用户'字段

主要是对urls.py的绝大部分需要监管的路由全部删除，改为由只有一个统一的re_path路由管理，并且指向为权限判定函数。

该函数通过接口请求过来的路由和接口携带的参数，通过数据库权限表来决定是否准许放行。

【通过views.py函数名控制】

此方案旨在views视图层拦截全部函数的执行，当接口进入需要调用函数的时候，必须先通过权限判定函数，并且传给函数名和接口所带用户id。

然后权限判定函数去数据库中找到该函数名关联的权限，再判断用户id是否在其‘关联用户’字段中

再考虑是否要放行。

【后记】：

很多公司的平台上的权限管理都极为混乱，互相冲突不断。且都不具备第三种方案的在线增删权限的能力，最多也只是在线对已有权限和用户 的关联关系 进行增删的能力。

在这种情况下，应该使用 三层权限 设计方案：

1. 固定写死权限 ：最高级别，写死到代码里，比如某个函数的执行内判断登录用户是否为特定超管。

2. 自定义特权：级别中等，由算法自动控制，在线增删改查。一旦某功能被自定义特权监管，则成与不成全看此。

3. 普通默认权限：级别最低，只有当某接口/函数 没有被固定写死权限和自定义特权 监管到的时候，才会使用普通默认权限，根据各个函数不同的特定规则，来决定是否执行。

若连普通默认权限都没有监管，则应全部准予放行。

好了，其实还有几种其他实现方案，今天就不说了