企业应用系统权限控制关键是类型抽象

对内容的访问控制可以抽象为全局权限；contenttype权限和行记录权限
对内容的访问控制可以抽象为全局权限；contenttype权限和行记录权限< p>昨晚睡得很好，今天加快进度，把事情做完它，装进LINUX，更新到网上去。上午效率不算太高，到博客上的时间偏多了一点。12：04分，完成了从 XML到解释的步骤，过去，在应用程序中调用时工作量最大，不过现在由于程序都是现成的，只是扩展方法而已，因此估计速度会快得多。按昨天的设想，是把 action增加一个空的doAuthorize()方法，这样不会影响已有的程序的调用，而在需要时可以添加这个方法实施代码，特殊情况下可以覆盖这个方法的代码实施特别的控制。在版面显示的涉及到内容采集的tag模块中也可以采用这个方法。

 

昨天对设计出来的结构：

<privileges>
 <privilege name="ownerid" fld="id" vname="id" scope="visitor"/>
 <privilege name="ownername" fld="name" vname="name" scope="visitor"/>
 <roles>rolesadmin</roles>
</privileges>
<privileges>
 <privilege name="owner" fld="author" vname="name" scope="visitor"/>
 <display>ALL</display>
 <roles>bbsadmin</roles>
</privileges>

理解仍不充分，实际上，privileges意味着是对contenttype的访问权限；而privilege意味着是行级权限。这样，authrize ()中就不会处理到privilege这一层，这一层是由拥有dao实例的处理层进行处理的，违反这个原则必然带来代码的冗长和性能的代效。< /p>

这个问题似乎进一步想清楚了，其中，行权限的前题是拥有者，这对于modify型，包括delete都有效，但对于添加没有效果。在这个问题上最容易犯的是不能明确使用的是黑名单方式还是白名单方式。毫无疑问，在这里我采取的是白名单方式，因此，即使是对于display权限，也必须明确授予才有效，毕竞象个人资料是不可以让其他人看的。更新文档如下：

六.实体的访问权限设置
系统权限完全采用白名单方式，未经许可一律禁止；默认地，Administrator组成员拥有所有的权限；验证过程对于action来说，是提供一个 authok=true|false的参考值，是否采用由程序本身决定，除非出现异常。
1、privileges对象和privilege对象

<privileges>
 <privilege name="ownerid" fld="id" vname="id" scope="visitor"/>
 <privilege name="ownername" fld="name" vname="name" scope="visitor"/>
 <roles>rolesadmin</roles>
</privileges>
<privileges>
 <privilege name="owner" fld="author" vname="name" scope="visitor"/>
 <display>ALL</display>
 <roles>bbsadmin</roles>
</privileges>

 

真正需要设置的是privileges和privilege;
2.privileges表达了这样的意思：对于这个实体的访问，以下的组内的用户都可以接受；默认地Administor组是可以获得对所有实体的访问权限；这里实际上是对这个contenttype的权限；
属性：
privileges.roles;以"role1,role2"格式列出，表示有完全访问权限的组；
privileges.display/modify/deleted//append等；表示只有其中的组列才拥有相应的权限；在实际操作中将通过 BaseAction.checkEntityRight(visitor,stype)方法根据不同的BaseAction.extends类型调用不同的stype实现contenttype的类型权限验证

3.privilege实际上是一个if条件式的对象；表达这样的意思：如果名为xx这个条件成立，那么就检查该条件是否有roles相连，如果有，这些组内的成员获得访问权限；如果没有，只有条件成立任何人可以获得访问权限；

4.类似thread目录这样的与子孙继承有关的权限；不在这里实现（TMD的太复杂了，通用性不强，按原来的针对页面进行控制）；
5.、访问权限有append/delete/modify/display，默认地，只要拥有前面三个中任何一个权限，同时拥有display权限；拥有display权限不等于拥有前面的权限；display由于涉及到前台发布的自然许可，所以主要在页面逻辑上实现。
6.privilege对象属性解释：
fld:用于对比的域；
scope：用于取对比值的来源，包括visitor;base等；（或者包括section）,注意，这与jsp变量的scope是不一样的；如果来源于base,是base:basename:recordname的格式
value:这是比较简单的直接赋值；
vname:如果value有值这条就免了，但鬼才记得那个归那个的ID，还是名字好记，所以这用于从scope中拿值；
roles;同privileges,多个组间用逗号相隔

7.这里并不能覆盖所有的操作，其中默认对Administrator的许可，注册的许可，以及对基树节点不同的许可，由各自的程序特别扩展完成。

基表系统中的multitree仍然没有完成，不过就完成的部分而言，仍然是没有写一个足够详备的文档参考，在调用时仍然是觉得生疏，今天仍然需要一个个看到代码才有一点印象，尽管代码是我写的。当初做dao.xml时，para的hbase是通过xxxbase提示，这看来是多余的，实际上，所有的base都是统一通过getBase()得到。对于treebase来说，尽管已经在admin中广泛调用，但作为一个类似下拉表的应用来说，我还没有印象，即使是那个loadRecords我也没有印象曾经调用过，这里需要重新整理一下。对于权限检验这一条来说，其中涉及到根据某一个基表名称的某一个基对象的名称进行验证，显然，这更象是当成一个simplebase进行访问，所以，需要修改这几个类统一下方法。实际上，尽管象treebase已经提供了几乎全部的parent/son链表关系，以及leafs/records，但却没有真正进行过调用，原因在于 tree/contentsmanager的内容浏览器中是通过lister调定列表条件进行访问的，完全没有使用treebase的功能。不过，由于那个的修改是实时进行的，而treebase 是一次性读入内存中周期刷新的，所以，目前这样处理也不是一件坏事，以后，可以扩展lister使用这个treenodes，相信是完全可以做到的，这时侯，适用于是只读的操作，最合适不过。从性能上看，lister是高效的查表程序，而lister 读入的基类，当需要找children时，却是必须通过递归实现的，效率上看，换成treenodes形式倒不见得是一个划算的选择。

回过头来再看看base部分，这是很早以前完成的基本功能的，在调用时问题不小，特别是没有使用反射，所以在类判断上显得比较的笨拙。收改了这个地方，另外，包括是xxxbase:basename的形式也同时更改过来了。

全天仍没有完成最后权限控制部分对action的所有修改，更不用谈提交linux服务测试。这件事仍需要再有半天到一天才能完成