“函数式”和“面向对象式”在权限引擎中是如何融为一体的?

15-02-07 liangshan
              

Function和Operation的异同

Function是绑定在ResourceType(class)上的,一种资源类型上有一个Function列表。record(object)从ResourceType(class)继承这些Function列表。这种绑定在对象上的函数叫Method,而绑定在ResourceType上的函数叫Operation,它们的名字不同只是因为所处的层次不同,ResourceType + Operation + Field是面向软件的最终用户的,而Class + Method + Property是面向开发人员的,核心区别仅此而已,别的区别都是细节。

把控“资源”和“功能”的正交关系

现在有这样一个问题:比如卧室里有“空调”、有“电风扇”,这两种资源都有“降温”的能力(功能)。

我想直接控制“降温”权限,而不是分别控制“使用空调降温”和“使用电风扇降温”怎么办呢?这里的“降温”可以认为是Function,而“使用空调降温”和“使用电风扇降温”可以认为是Operation,因为它们绑定到了资源上。“降温”能力集是比“使用空调降温”和“使用电风扇降温”能力集更大的能力集。

把函数固定在对象上,先定位对象然后再定位函数,将对象视为函数的耦合作用域(函数中传入的this对象)这是面向对象的方法论。把函数和对象分开然后通过(Function, Input, Output)组合成三元组这是函数式方法论。

在OO世界中,由于Function已经被绑定到Object和ObjectType上去了,所以当房间里有“空调”和“电风扇”这两种降温资源的时候我们若要控制某个主体不能降温的话就只有分别控制他不能“使用空调降温”和“使用电风扇降温”了。

试试通过变换资源树的结构能否解决上面那个问题呢?

+制冷设备

----电风扇(ResourceType)

--------电风扇降温(overwrite Operation)

--------风扇1(电风扇类型object1)

--------风扇2(电风扇类型object2)

----空调(ResourceType)

--------空调1(空调类型object1)

--------空调降温(overwrite Operation)

----降温(Operation)

现在,如果我们直接不让某个主体不能使用“制冷设备”下的“降温”功能的话是可以做到使他既不能“使用空调降温”也不能“使用电风扇降温”的。

但是,空调除了是“制冷设备”还是“制热设备”。重绘一下上图的树会是这样。

+制冷设备

----电风扇(ResourceType)

--------电风扇降温(overwrite Operation)

--------风扇1(电风扇类型object1)

--------风扇2(电风扇类型object2)

----空调(ResourceType)

--------空调1(空调类型object1)

--------空调降温(overwrite Operation)

----降温(Operation)

+制热设备

----空调(ResourceType)

--------空调1(空调类型object1)

--------空调制热(overwrite Operation)

----制热(Operation)

融合“面向对象式”和“函数式”

问题出来了:“空调”节点在资源树上出现在了两个位置。这违反了树形结构,违反了构造定理,所以我们错了。

我们得从资源树上“剪掉”制冷设备和制热设备这两个节点,得把它们放入新的维度中去。那个新的维度是什么?是函数维度。上面我们遇到的问题是因为我们钻到资源树这一棵树中去了,“制冷设备”“制热设备”中的“设备”是资源,而“制冷”和“制热”是函数。

从资源的角度永远没办法解决空调既出现在制冷设备节点下又出现在制热设备节点下这个问题。资源和功能组合起来后就很好的解决了。(使用空调制冷"Operation",制冷"Function")(使用空调制热"Operation",制热"Function")(使用电风扇制冷"Operation",制冷"Function")(使用电热扇制热"Operation",制热"Function")。

函数(能力、运动、时间)是适合组合到资源(空间)上的,只有与特定类型的资源十分紧密依赖的函数才是可以沿着资源树继承的。

在Anycmd这个开源权限引擎中断言过(Function, Function)这种类型的二元组是有意义的,现在终于几乎确定找到了它的意义。(使用空调制冷"Operation",制冷"Function")这个二元组就是(Function, Function)类型的二元组(Operation集是Function集的子集,Operation是特殊的Function)。

(Function, Function)类型的Privilege二元组

(Function, Function)这种二元组目的是建立Function之间的层次关系。

在appSystem节点上(appSystem节点是根,虽然在空调和电风扇共同的任意父节点上都行但最佳应在appSystem这个根节点上,根节点是Global对象)添加一条命名为“制冷”的Operation记录。然后建立(使用空调制冷"Operation",制冷"Function")(使用空调制热"Operation",制热"Function")(使用电风扇制冷"Operation",制冷"Function")这种(Function, Function)类型的二元组合。表示“电风扇制冷”和“空调制冷”继承“制冷”,从而安全引擎鉴权当前请求“空调制冷”的主体是否有权限的时候找到“空调制冷”这条Function记录的父级记录“制冷”,然后鉴权是沿着Function的层次进行一级一级向下进行的,如果当前主体没有“制冷”权限就直接没有权限了,如果有“制冷”权限再接着验证“空调制冷”权限。

需要提及的是:

制冷”这条function记录并不对应实际的程序员书写的功能代码,而只是一条记录,这条记录的目的只是为制冷这种功能取个名字生成一个标识,然后用来和业务系统中的绑定在资源上的那些“操作”(绑定在资源上的Function称Operation)建立(function, function)类型是组合从而表达功能间的层次关系。

权限引擎在智能家具领域的应用:

上面那种逻辑在智能家居中可以应用。1 比如家长担心使用电风扇制冷存在安全风险(担心小孩子会将线头布条输入旋转的电风扇中),所以家长主体可以将家居这个appSystem环境设置为当只有小孩子一个人在家的时候系统拒绝小孩主体打开电风扇,但允许小孩子打开空调;2 当家居中的主体数量大于3人时空调和电风扇可以被同时打开,当少于3人时只能打开其中之一。即使最终用户有任意复杂的授权和鉴权需求Anycmd开源权限引擎几乎都能满足。

              

banq
2015-02-09 20:24

用函数方式解决权限可能会更巧妙点,函数自己的动作也可以组成树形结构,比如xxxx.canDo1().canDo2().canDo3()

这也就看出,权限Do3包含在权限Do2中,Do2包含在Do1权限中。

仅供参考。

liangshan
2015-02-10 08:34

2015-02-09 20:24 "@banq"的内容
用函数方式解决权限可能会更巧妙点,函数自己的动作也可以组成树形结构,比如xxxx.canDo1().canDo2().canDo3()

这也就看出,权限Do3包含在权限Do2中,Do2包含在Do1权限中。

仅供参考。 ...

是的,最终目的是想要得到一个像CLR和JVM中那样的,内部有这样几个记录集合的设计:类型集(目录表)、方法集、字段集(目录表)、方法参数集,然后对这几种记录进行组合,通过组合和解释它们来运行上层的访问控制策略。目前正在验证,通过学习可以在之上运行C#也能运行F#的CLR的资料来验证一下现在的设计。验证的过程中预演2.0,预演了2.0发1.0。(1.0处理功能级和目录级权限问题,2.0处理记录级或者称对象级以及更细粒度的权限问题)

// 修正错别字

[该贴被anycmd于2015-02-10 10:24修改过]

freebox
2015-02-11 08:58

如果把设备和功能看成一个矩阵就好办了

class/method,AC, Fan

cold, true, true

hot, true, false

这样可以把具体的方法代理出来,取得调用者的类名和调用方法名,在矩阵里验证一下权限,通过就继续调用,不通过就掷出权限异常。

[该贴被freebox于2015-02-11 08:59修改过]

liangshan
2015-02-11 10:53

2015-02-11 08:58 "@freebox"的内容
如果把设备和功能看成一个矩阵就好办了 ...

同意,矩阵可能是从两棵树上分别取一个节点组成个二元组,所有的二元组组成个集合,然后对这个集合再做没有层级的单元划分,然后把这些单元集平铺到一个平面上去。

// 追加

(谁?)不要管它对不对。我也不知道为什么,读书时我根本没弄懂的那些知识,现在都自然的扑过来。

“知识”是名词,然而单独的“知”和“识”却是动词。构造定律无处不在,不是理解了自然的人们主动按照构造定律去建造事物,而是构造定律驱使着我们按照自然的意愿去建造事物,不按照它的意愿来它就不让这些事物延续。

“知”和“识”是运动,是变化,是时间,是Function。

“知识”是资源,是空间,是Resource。

[该贴被anycmd于2015-02-11 12:19修改过]