多应用+插件架构,代码干净,二开方便,首家独创一键云编译技术,文档视频完善,免费商用码云13.8K 广告
## 权限设计 权限其实蛮复杂的,这里不同用户,不同类型的使用者都有各自的权限,特别是还涉及到企业微信成员对应用的权限控制。 根据使用对象,我们需要分为几个层面来分别设计权限控制。 >[danger] 权限做得复杂可以很复杂,很完善,也可以做的很简单,初期简单、有效就可以了,不需要做的太复杂。不然就犯了“过早地把系统设计得太复杂”的问题,这和“过早的优化性能是万恶之源”差不多。 * * * * * ### 思考 ~~~ 有一些东西是基础设施,比如班级管理,有一些是应用,真是傻傻分不清。 还是一刀切算了,直接用应用做,必须班级管理就是应用。 烦,系统,应用,管理,权限,企业微信应用,还没有很好的设计出他们的关系,烦!!! 再来看应用权限 应用前台针对于成员,后台针对于管理员。 同时还有常规的节点权限,应用权限(应用管理/可见权限和应用节点权限) 对于后台管理来说,应用是学校管理员、老师的使用权限(可见权限和后台节点权限) 对前台使用来说,应用是成员的使用权限(可见权限和前台节点权限) ~~~ ### 扩展思考 权限分为两类: 后台权限,和前台权限。 后台权限是管理员权限,各项操作或者应用的功能权限。 前台权限是成员使用应用的权限,包括应用可见权限(这个由企业微信成员通讯录可见范围控制),和应用功能的控制。 ~~~ -- 权限要注意的是,不仅要控制可见,也要控制实际的应用权限,因为即使应用不可见,用户还是能记住url使用应用,所以要做真实的权限控制 -- 目前接口不能设置应用的可见范围,但是也没事,毕竟应用的使用人群是固定的,比如事先就规定,“校长信箱”只能是家长使用的,那么业务员前期的准备工作就是做这些,将“校长信箱”的可见范围设置为家长部门,我们要做的就是控制谁加入家长这个部门就行了,权限以这种思路来做,如果以后接口支持更强大就方便多了。 -- 【应用更细化的权限控制】(细化到操作)(不同角色可能有统一模块的可见权限,但是具体的操作权限可能不同) -- 【成员】 -- 前台 应用可见权限(细化到部门和成员,上面已经实现) -- 前台 操作权限(细化到部门和成员) -- 【学校管理员】 -- 后台 应用可见(管理)权限(细化到角色和账号) -- 后台 操作权限(细化到角色和账号) -- 【老师】 -- 后台 应用可见权限(细化到角色和账号) -- 后台 操作权限(细化到角色和账号) -- 应用权限规则(节点,注意这个分为前台和后台) 表 -- 部门/角色/成员/账号 & 规则 关联 表 ~~~ * * * * * ### 成员 权限 成员(老师,家长),应用的可见权限,和应用的节点权限。 * * * * * ### 学校管理员 权限(不是老师) 管理员应用的可见权限,和应用节点的权限。 还有常规的节点权限。 * * * * * ### 学校老师 权限 老师应用的可见权限,和应用的节点权限。 同样有常规的节点权限。 (老师和学校管理员类似,也可以管理学校,本可以设计为学校管理员表中的一个角色,但是由于老师和家长一样,都是前台的使用者,都是成员,所以比较特殊,为了方便管理,所以**老师用户账号**表就是成员表,和学校管理员分开设计了。) **学校中的老师不是用户,成员才是用户,学校中的家长不是用户(一个人可以为好几个学生的家长,甚至可以为好几个学校的学生的家长),对应的成员才是用户,理解这个很重要,这是身份于账号的关系,账号是独立的个体,而身份是依附于账号的。** * * * * * ### 最终的权限设计 - 应用权限 - 常规权限 **应用权限:** <table> <tr > <th rowspan="2" style="color:red;">应用权限</th> <th colspan="2" align="center" style="text-align:center;">前台</th> <th colspan="2" align="center" style="text-align:center;">后台</th> </tr> <tr> <th>可见权限</th> <th>节点权限</th> <th>可见权限</th> <th>节点权限</th> </tr> <tr> <th rowspan="2">权限</th> <td>成员的可见权限</td> <td>成员的节点权限</td> <td>管理员的可见权限</td> <td>管理员的节点权限</td> </tr> <tr> <td></td> <td></td> <td>老师的可见权限</td> <td>老师的节点权限</td> </tr> </table> **常规权限:** <table> <tr > <th rowspan="2" style="color:red;">常规权限</th> <th align="center" style="text-align:center;">前台</th> <th align="center" style="text-align:center;">后台</th> </tr> <tr> <th>节点权限</th> <th>节点权限</th> </tr> <tr> <th rowspan="2">权限</th> <td></td> <td>管理员的节点权限</td> </tr> <tr> <td></td> <td>老师的节点权限</td> </tr> </table> 前台都是应用,所以只有应用权限没有常规权限。权限都是在后台设置。(设置权限 的 程序节点 是 常规权限 的 节点权限) **<span style="color:red;">这些节点需要自己创建(系统定义),而应用的节点需要开发者提供,如:</span>** `XX操作:do=xxAction` >[danger] 权限节点(应用如果要支持精细的权限节点,就可以进行配置) * * * * * ### 关于内建应用 的权限 内建应用可能没有应用后台,而是通过系统后台直接管理的。 所以内建应用的节点规则可能包含了应用前台和系统后台,或者应用后台。 总之内建应用比较灵活,不像常规应用那么标准。 内建应用定义 **非常规的应用节点** 时怎么定义呢? 常规定义是:`XX操作:do=xxAction` 如果内建应用想定义 **非常规的应用节点** 是这样定义的: 直接定义完整节点就可以:module/controller/action * * * * * ### 权限控制所需要的表 #### 应用权限 **节点权限** - 成员(前台)-应用权限节点 关联表:`学校ID,应用ID,节点名称(XX操作),节点名(前台xxAction),成员ID` - 管理员(后台)-应用权限节点 关联表:`学校ID,应用ID,节点名称(XX操作),节点名(后台xxAction),管理员ID` - 老师(后台)-应用权限节点 关联表:`学校ID,应用ID,节点名称(XX操作),节点名(后台xxAction),老师ID(其实是成员表ID)` (应用节点一般比较少,所以这里没有角色,用户直接和节点关联) **可见权限** - 成员(前台)-应用可见权限表:`学校ID,应用ID,obj_id,type(部门或成员ID)` - 管理员-应用可见权限表:`学校ID,应用ID,管理员ID` - 老师-应用可见权限表:`学校ID,应用ID,老师ID(其实是成员表ID)` 应用权限需要6张表。 #### 常规权限 管理员节点权限(auth的四张表) 老师的权限节点表(auth的四张表) * * * * * last update:2017-9-21 14:06:25