本文讲解4.4版jxTMS中的动态管控，整个系列的文章请查看：docker版jxTMS使用指南：4.4版升级内容
docker版本的使用，请查看：docker版jxTMS使用指南
4.0版jxTMS的说明，请查看：4.0版升级内容
4.2版jxTMS的说明，请查看：4.2版升级内容
之前的文章中我们讲解了jxTMS提供的python侧的REST用户权限控制，主要是通过【资源组-操作-角色】的关联来进行授权访问。
但除了这种主要用于数据/资源操作的权限管控之外，就系统管理而言，可能还需要其它的管控手段。如，临时性的禁止访问、限制用户操作的频次等等。
针对这种面向系统或业务管理的管控需求，jxTMS提供了动态管控机制。
动态管控是用户可自定义的管控机制，jxTMS会在几处关键点进行集中检查，只要不通过任何一项检查都拒绝继续执行。
注：也可根据需要自行检查，可参考后文的讲解
动态管控分为资源管控、用户管控两部分，都提供了注册接口用于注册自行定义的管控手段：
resource类动态管控
setDynamicallyCheck(cls, checkItem, dual)
注册一个针对资源的动态检查项
参数：
checkItem：检查项名
dual：检查函数函数
说明：
dual函数的签名为：
dual(resID,op,u)，其中：
resID：资源ID，就是用户访问时提供的resID参数
op：操作名，就是用户访问时提供的op参数
u：当前用户，即是谁希望对resID执行op操作
注：jxTMS在注册时不检查重名与否，所以用户可以用自己编写的动态检查来覆盖jxTMS内置的黑名单等动态管控措施
jxTMS在初始化时，自动注册了一个名为blacklist【黑名单】的资源动态检查项。如果resID被加入了黑名单则对其任何操作都会被拒绝。添加与移除黑名单通过：
blacklistAdd(cls, resID)
将resID加入资源黑名单，其后对resID的任何操作都会被拒绝。即刻生效
参数：
resID：资源ID，就是用户访问时提供的resID参数
示例：
resource.blacklistAdd('demo_1')
#拒绝对demo_1的访问
blacklistRemove(cls, resID)
将resID移除资源黑名单，即刻生效
参数：
resID：资源ID，就是用户访问时提供的resID参数
user类动态管控
setDynamicallyCheck(cls, checkItem, dual)
注册一个针对用户的动态检查项
参数：
checkItem：检查项名
dual：检查函数函数
说明：
dual函数的签名为：
dual(u,op,resID)，其中：
u：当前用户，即是谁希望对resID执行op操作
op：操作名，就是用户访问时提供的op参数
resID：资源ID，就是用户访问时提供的resID参数
和资源管控类似，jxTMS在初始化时，也自动注册了一个名为blacklist【黑名单】的用户动态检查项。如果用户名被加入了黑名单则其任何访问都会被拒绝。添加与移除黑名单通过：
blacklistAdd(cls, userName)
将userName加入用户黑名单，则该用户的任何访问，包括登录与操作都会被拒绝。即刻生效
参数：
userName：用户名
示例：
resource.blacklistAdd('demo_user_123')
#拒绝demo_user_123的登录与任何操作请求
blacklistRemove(cls, userName)
将userName移除用户黑名单，即刻生效
参数：
userName：用户名
除此之外，jxTMS在初始化时，还自动注册了两个访问频率的动态检查项，一个是登录频率管控、一个是操作频率管控。
登录频率管控
我们之前介绍rest访问的用户登录时，曾指出用户有一个控制性属性：是否允许强制登录。即当某个用户已经登录时，是否允许抛弃现有会话而让用户重新登录。
如果不允许强制登录，则只有当前会话超时后，才允许重新登录。但这意味着当一个新用户在测试阶段，重启后必须等待15分钟后才能再次登录完成测试工作。
设置这一属性主要是因为jxTMS强制一个用户只能有一个会话，以在用户名、密码泄露时能尽快的发现从而降低安全风险。但如果出现密码泄露，在允许强制登录时，就会出现不同的点反复登录的情况，系统只会观察到某用户每次都是执行操作前先登录，而无法发现此安全隐患。
针对这一问题，利用动态管控机制，jxTMS对用户登录的管控做了进一步的优化：
-
一般性用户，默认允许每天三次登录【登录后15分钟内的任何访问都会自动展期而不会超时】
-
对于新开的、需要测试的用户，可通过jxTMS管控平台下达临时性豁免命令，给予10天的豁免期，在豁免期内部不限制登录频率，10天后自动取消临时性豁免
这样一来，当出现密码泄露时，由于jxTMS强制一个用户只能有一个会话，很快就会因出现用户无法登入的问题从而将安全隐患暴露出来。
用户操作频率管控
利用动态管控机制，jxTMS还给每个用户设置了操作频率管控。频率控制共涉及到三个参数：
-
限制周期，即频率管控的计数周期，一般以秒为单位
-
限额，限制周期内允许的最大访问次数
-
超频数，当有类似DDoS攻击发生时，可能在短时间内爆发大量的访问，虽然超过限额的都会被拒绝掉，但这些访问依然还是要执行上述的这些检查，所以还是会消耗大量的系统资源，所以当限制周期内的访问次数超过超频数后，jxTMS会自动将用户临时加入到黑名单中12个小时，使得其在第一时间就被拒绝掉
注：超频访问临时拉入黑名单是登陆用户的操作过于频繁所导致，其诱发原因，一是测试时程序出了bug，二是密码泄露了
动态管控的卡控点
在执行动态管控时，有两种检查机制，一种是全部检查【可以排除掉某些特定的检查项】、一种是指定检查。
全部检查只有一个检查点，即用户想执行某项操作时：jxTMS会先执行用户全部的动态检查【排除掉登录频率检查，因为此时用户已经登录了】、然后执行资源全部的动态检查。
注：用setDynamicallyCheck自行添加的动态管控即在此时被调度执行审查
指定检查则有三处，都是针对用户的指定检查：
-
用户登录时，先指定执行黑名单检查
-
用户登录时，再指定执行登录频率检查
-
用户登录后的每次操作访问时，指定执行黑名单检查
注：资源的黑名单没有指定检查，但在用户执行某操作时会执行资源的全部检查，如果将某资源加入到黑名单中，则在此处会被拒绝操作的执行
动态管控的优点是比较灵活，用户可以自由的增加业务需要的动态管控措施。缺点也比较鲜明，因为jxTMS不清楚应该在何时、何处执行什么样的管控，所以只能在操作处理的主干道设立单一的管控点，不管什么资源、什么用户、什么操作，一股脑的将所有管控措施全部执行一遍，效率比较低。
所以如果数据处理压力比较大、资源比较紧张的应用场景下，最好减少全部检查场景下的动态管控的应用。
注：目前，动态管控和授权访问一样，都只用于外界通过REST访问系统。而REST访问都是toB的应用场景【主要是对少数约定好的资源执行特定的操作】，由于jxTMS已经提供了坚固的操作授权管控机制，所以jxTMS目前暂未提供用户审计，用户行为也基本不记录，除非打开trace才会对用户的所有行为及其结果进行记录
参考资料：
jxTMS设计思想
jxTMS编程手册
下面的系列文章讲述了如何用jxTMS开发一个实用的业务功能：
如何用jxTMS开发一个功能
下面的系列文章讲述了jxTMS的一些基本开发能力：文章来源：https://www.toymoban.com/news/detail-616506.html
jxTMS的HelloWorld文章来源地址https://www.toymoban.com/news/detail-616506.html
到了这里，关于docker版jxTMS使用指南：动态管控的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
