crm平台权限调研总结

权限系统调研

暂时抛开crm平台现有的这套权限控制，去看下常见的权限体系如何实现。根据业务的不同，实现场景会有区别，比如说角色限制、功能复杂度等，但是整体主流思想还是比较统一的。接下来，按照个人理解列举几个典型的，以供后续分析和参考。

位图思想

以下这段引用自知乎用户的一段话。

说一个我们现在用的，用二进制保存，一个权限对应一位，0是无权，1是有权，然后在需要某个权限的时候用一个二进制数去【与】或【或】运算，比如现在是101，需要判断第2，3位权限，就用011去与运算，或者是用100去或运算，如果true则有权，false无权。这样就可以一次判断多种权限组合的情况，而且读取数据库很快速，也能很节约。

这种思想，不是宏观角度，主要是实现细节上，乍一看觉得很有趣，有位图思想在里面，记录下。

访问控制列表思想

见名知意，访问控制列表思想相对较为简单。简言之，就是确保两个核心字段，分别为账号和权限。 数据库设计类似这样：

表： 主键，帐号，密码，权限

  1    *    *   1，2
  2    *    *   1，2，3
  3    *    *   2
  4    *    *   4

即把有权限的放入【权限】字段，通过权限字段来控制账号访问。 当然，还需记得针对权限字段，与实际权限做一个映射匹配。

基于角色的访问控制

基于角色的访问控制，在ACL的基础上，增加了一个关键词 角色 将之前的 账号<->权限 映射升级为 账号<->角色<->权限

当关键词为两个的时候，两个表就能表达。现在关键词增加1个，我们需要的存储信息如下

  1. 角色信息
  2. 权限信息
  3. 角色到权限的映射关系
  4. 用户角色信息

我理解的数据库设计如下：

角色信息 role表

表： 主键，角色id，角色名称，角色创建时间

  1    1    manager  2016-1-28
  2    2    sale   2016-1-28

权限信息 perm表

表： 主键，权限id，权限信息，注释

      1    1    can_xx,can_xxx  comment
      2    2    can_xx,can_xx   comment

角色到权限映射信息 global_role_perm

表： 角色id，权限id，更新时间，注释

      1    1,2,3  2016-1-28  comment
      2    2,6    2016-1-28  comment

用户角色信息 global_user_role

表： 账号id，角色id，更新时间，操作者账号

    liyujie 3     2016-1-28  zhuxi
    doumao  6     2016-1-28  zhuxi

crm平台权限系统现状

crm平台目前由user.conf和user表 两块构成。 其中 user表设计如下：

 表：  主键id  name     real_name   power         phone  email  remark
    
       1     liyujie   liyujie    3,5,6,7,10,11
       2     hanmeimei hanmeimei  2,12

user.conf设计分两块，分别为 简单角色定义

[power]
admin : 1
sale : 2
sale_assit : 3
sale_manager : 4
cfo : 5
inner_auditor : 6

通过ini配置文件的格式，定义power下的key-value值。 power配置目前业务适用场景为：

  1. 判断用户对应的power字段里是否包含super字段对应值，如果包含则删除op_name
  2. 判断用户为销售还是线索管理员还以及销售经理。主要是用来实现以下逻辑 <1>当进行线索分配时，判断是否为线索管理员 <2>线索列表展现时，通过判断是否为销售进行展现
  3. 订单浏览页面，获取用户是否具有ad_admin和super权限，以此决定是否给予订单add权限

uri访问限制

[uri2power]
[.customer_add]
power : 2,3,4


[.user_getinfo]
power : 1,2,3,4,5,6,7,8,9,10

uri访问权限控制，是通过根据定义好的url的字段，决定拥有哪些power可以直接访问or提交该uri。 结合如何所述，现状就是 我们是介于acl与racl之间的一种，本质上更偏重于acl，按照目前的需求，核心需求是两点 1、针对不同的uri对各类用户进行不同权限限制 2、支持管理员增删改查 用户角色和权限的功能，以及增删改查的记录

目前我们的第一点，基本满足，但是较为混乱，多种模式掺杂。 第二点还未提供页面支持。

CRM权限体系优化设计

因为CRM平台目前使用面向人数较少，整体优化宗旨是，在尽可能少的改动下让权限控制变得相对简单，同时提供后台权限管理页面，包括人员、权限的管理以及权限变更记录，确保平台数据透明。

基于上述宗旨，设计两点

  1. 全部统一为 通过uri进行权限控制。
  2. 在全部统一为uri控制后，设计后台权限管理。

uri权限控制

这块设计，数据交叉较多。 按照acl的思想，应该是每个url对应一个perm_id，然后用户和这个perm_id对应。 但是现在是 每个url对应了一堆id,用户又和这一堆id做对应。然后交叉寻找权限是否存在，无意中增加了循环的复杂度。

所以期望设计成如下 每个uri (perm_name) <-> 对应1个id（perm_id） 每个用户(user_name) <-> 对应到多个perm_id 用户权限操作记录表 user_name perm_id op_name op_time

上述映射关系用两个表进行，另外挑出一张表用来做操作记录。

后台权限管理平台

  1. 权限管理页面 增删改查权限信息
  2. 用户权限管理页面。增删改查用户对应权限信息
  3. 用户操作记录。确保有据可查。记录 每次用户权限变更的操作人以及时间。