对内容的访问控制可以抽象为全局权限；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服务测试。这件事仍需要再有半天到一天才能完成
