jxTMS设计思想之权限

jxTMS是以低成本快速定制为核心诉求的、SaaS模式的二次开发平台，详见：jxTMS简介。本文是讲述jxTMS平台中权限部分是如何设计的，整个系列请访问：jxTMS设计思想

权限在jxTMS表达的非常简单：是否有权执行一个入口。

在组织管理中，存在着一系列相关的概念：职务、职位、职能、职权、职责。在jxTMS看来，一个入口对应一项职权，一组职权组成了一个职能，多个职能构成了一个职务，而职位是从组织架构的层面来看职务，主要表现在审批流程中的职务排序。

职责意味着对操作结果负责，由于jxTMS无法通用的、一致的判断操作结果的好坏，所以职责的判定不在jxTMS范围之内，jxTMS需要负责的是提供日志、现场数据、快照、数据变动等工具集来全面的、交叉的对用户操作进行记录，用于事后的审计与追溯。

职务、职位、职能、职权等，jxTMS统一用角色来进行概括与衔接。即在组织管理中，角色是职务，具体分配给某个成员，该成员使用该角色所拥有的职权来访问各入口。

而在运行时，各入口可以分配给一组角色，拥有相应角色的成员就可以看到并访问该入口，没有指定角色的入口就意味着所有成员都可以访问。

为了更好的组织，角色又可细分为真实角色和虚拟角色，两者的区别在于：

• 真实角色才可以映射给具体的成员，虚拟角色不可以映射给成员

• 虚拟角色需要映射给真实角色，映射后真实角色也就同时拥有了所有映射到自己的虚拟角色的职权

大略的说，jxTMS中用虚拟角色来接受职权组成一个个职能，然后通过给真实角色映射或解除映射各种虚拟角色，从而在各个职务之间微调各种权限，最后将真实角色映射给各成员使得各成员可以完成组织需要他们完成的工作。

但出于灵活性的考虑，入口并非一定只能指派给一个虚拟角色，其不但可以指派给真实角色，也可以一次指派给多个角色。

权限检查点

在jxTMS刚开发成型的时候，由于当时只考虑动态web界面这一种UI，所以权限检查被前置到了web端请求菜单、快捷栏和工具条时，没有权限就不发送相应的入口，即jxTMS在发送菜单和快捷栏、工具条栏时，是根据当前用户映射的角色来查询这些入口，然后发送给用户前端的。

但后来由于某个项目对界面美学的需要，笔者用jxTMS做后端来支持由前端工程师开发的静态web界面，这种方案就出现了问题：所有入口都要暴露给前端，前端完全可以不顾op.py中入口的角色设置随意调用任意的入口。

针对这一需求所暴露出来的漏洞，jxTMS又增加了一道权限检查，即在请求到达后，在加载相应的capa准备投入执行前也增加了入口的权限检测，从而弥补了这一漏洞。

这就是jxTMS中的两道权限检查：前一道是入口的授权后的动态绘制；后一道是入口被点击【也就是相应的事件响应函数被触发】后，jxTMS会坚持该入口是否在用户的角色-入口对应关系中。

但由此又带来了一个问题：在入口一章中我们说过，jxTMS有四种入口，其中前三种是定义在op.py中的，这三种是可以指定角色来进行权限检查的，但最后定义在web界面中的入口其权限该如何处理呢？

非常简单，定义在web界面的入口其自身没有权限，采用跟随策略，即哪个用户有权限打开其一个web界面，则jxTMS会增加临时授权，将该web界面中所有静态定义的入口都添加到该用户的临时授权中。这就既统一了入口的权限检查，又简化了web界面中各入口的设计。

目前jxTMS已经开放个人注册试用，欢迎大家注册试用：

注册到jxTMS

下面的系列文章讲述了如何用jxTMS开发一个实用的业务功能：

如何用jxTMS开发一个功能

下面的系列文章讲述了jxTMS的一些基本功能：

jxTMS的HelloWorld