权限系统与其附带的权限审核控制是中大型企业必可少的,本文从权限系统的基本实现和如何接入审核两个维度来探讨。
目录
常见权限系统中不同权限之间一般是父子关系,即申请A权限之前一定需要申请B权限。一个权限节点可能有多个子权限节点,也可能有多个父亲。对于用户来说,每个user自身拥有的权限也需要记录。
权限表:permission_id是主键,每种权限必须具备描述、类别、父节点、创建人、是否生效、修改人这些信息 。
对于比较复杂的系统,可以设置管理员权限、操作员权限、访客权限,每个权限初始化一些自身拥有的权限 ,如果需要申请新的权限可以去审核平台申请
角色表需要有主键、该角色的姓名、角色类型、关联的权限id、创建时间与更新时间这些信息
一些关键接口
- private List
fillChildrens(List permissionNodes, long parentPermissionId) { - List
currentPermissions = permissionNodes.stream() - .filter(p -> parentPermissionId == p.getParentPermissionId())
- .collect(Collectors.toList());
- List
resultPermissions = new ArrayList<>(); - for (PermissionNode permissionNode : currentPermissions) {
- long currentParentPermissionId = permissionNode.getPermissionId();
- List
childrenPermissions = fillChildrens(permissionNodes, currentParentPermissionId); - resultPermissions.add(PermissionNode.newBuilder(permissionNode)
- .addAllChildren(childrenPermissions.stream()
- .sorted(Comparator.comparing(PermissionNode::getPermissionId)).collect(Collectors.toList()))
- .build());
- }
- return resultPermissions;
- }
一般而言,公司内部审核分为行政管理类和业务维护类;前一种可以直接根据公司组织架构生成审批流,后一种可以更具当前业务的维护人员熟悉程度动态生成审批流。
审核表
name | type | description |
audit_id | int | primary key |
permission_id | int | permission id |
type | int | audit type |
requester_name | varchar | requester_name |
reviewers | varchar | array of reviewers |
reason | varchar | reason |
开权限类型的审批审核完成后,往往是修改申请者关联的权限表中的某个字段,这种比较简单。如果是审批完成后需要执行某个耗时长或者复杂的操作,这时作为审核业务的owner需要设计开放api,让审核业务的请求方填写业务回调地址与参数列表,可以在审核流程结束后,以http接口或者消息队列的方式call back,实现业务流程的自动化。