关于用户角色权限管理一点想法

能不能归纳出一个通用的用户角色权限管理?答案是肯定的,其实这可以使用工作流机制实现。

确定好用户权限系统中的实体是系统分析的首要工作,我比较同意这样一种划分:

1.访问者(User)
2.被访问者
3.权限

以上三个各自都是自成系统,关键是在这三者之间制定规则,这样的规则是复杂的,静态的,也可以是动态的,有条件限制和时间限制。
系统的难点是在如何开发出一套通用的规则制定上,看来使用if else这样的计算机化形式不是一个很好的办法,因为不是所有的用户都有计算机人员那样严明的逻辑思考和归纳能力。

JAAS不是很好的吗?我不是太了解

其实工作流中的组织模型和权限也是一个比较麻烦的事情,问题在于扩展和通用。如果写死的,还是挺简单

JAAS完成简单的用户验证是没问题,但是对于象网站引擎系统这样大系统,用户验证是很重要的部分,而且需要自定义,我觉得就最好自己来做了。

F.Y.I
An universal security data model defination from an open source project.

<entity entity-name="SecurityGroup"
package-name="org.ofbiz.commonapp.security.securitygroup"
title="Security Component - Security Group Entity">
<field name="groupId" type="id-ne"></field>
<field name="description" type="description"></field>
<prim-key field="groupId"/>
<relation type="many" rel-entity-name="UserLoginSecurityGroup">
<key-map field-name="groupId"/>
</relation>
<relation type="many" rel-entity-name="SecurityGroupPermission">
<key-map field-name="groupId"/>
</relation>
</entity>

<entity entity-name="SecurityGroupPermission"
package-name="org.ofbiz.commonapp.security.securitygroup"
title="Security Component - Security Group Permission Entity">
<description>Defines a permission available to a security group; there is no FK to SecurityPermission because we want to leave open the possibility of ad-hoc permissions, especially for the Entity Data Maintenance pages which have TONS of permissions</description>
<field name="groupId" type="id-ne"></field>
<field name="permissionId" type="id-long-ne"></field>
<prim-key field="groupId"/>
<prim-key field="permissionId"/>
<relation type="one" rel-entity-name="SecurityGroup">
<key-map field-name="groupId"/>
</relation>
<relation type="one" rel-entity-name="SecurityPermission">
<key-map field-name="permissionId"/>
</relation>
</entity>

<entity entity-name="SecurityPermission"
package-name="org.ofbiz.commonapp.security.securitygroup"
title="Security Component - Security Permission Entity">
<field name="permissionId" type="id-long-ne"></field>
<field name="description" type="description"></field>
<prim-key field="permissionId"/>
<relation type="many" rel-entity-name="SecurityGroupPermission">
<key-map field-name="permissionId"/>
</relation>
</entity>

<entity entity-name="UserLoginSecurityGroup"
package-name="org.ofbiz.commonapp.security.securitygroup"
title="Security Component - User Login Security Group Entity">
<description>Maps a UserLogin to a security group</description>
<field name="userLoginId" type="id-vlong-ne"></field>
<field name="groupId" type="id-ne"></field>
<prim-key field="userLoginId"/>
<prim-key field="groupId"/>
<relation type="one" rel-entity-name="UserLogin">
<key-map field-name="userLoginId"/>
</relation>
<relation type="one" rel-entity-name="SecurityGroup">
<key-map field-name="groupId"/>
</relation>
<relation type="many" rel-entity-name="SecurityGroupPermission">
<key-map field-name="groupId"/>
</relation>
</entity>

O!!, the html tag was filted?

谢谢
这样一个open source的网址在哪里?我正在策划这个项目,如果有现成的可参考,就非常的棒。

html代码是过滤的。

它的工作流作的不错的
ofbiz.org


http://www.ofbiz.org/

ofbiz是我遇到最难搞定的软件,半天功夫还不能运行,头疼。

是我下载错误,应该使用complete版本

这东东好,就是速度慢,也难怪,J2EE已经效率不是很高了,在上面多加几层,那不累吗?

这东东把当前web商务应用总结成几大块:
1.服务引擎
2.工作流引擎(做好工作流已经不错,还要做引擎,要多高深的思想和技术啊,我的嘴已经张大半天,没法合拢了)
3.规则和约束
4.实体引擎
5.数据分析
6.内容和知识

我敢说这东东一定是学校里的老师或学生搞出来的,现在问题是,上面每一块都在发展,而且都会发展成一门独立的学科,到将来,这个软件框架要多大啊。

研究过ofbiz的说说看法,楼上提到的用户安全验证那块具体在哪里?

我觉得ofbiz是进行web商务开发的一个学习课程,通过ofbiz可以从理论高度理解我们平常认为很简单的 网上商店 产品目录等概念。

>>是我下载错误,应该使用complete版本
呵呵,complete版本下载下来就可以用的

>>这东东好,就是速度慢,也难怪,J2EE已经效率不是很高了,在上面多加几层,那不累吗?
速度一点也不慢,我们的Intranet 的Portal就是用它开发的,每天10W次的访问量,下载下来的东西慢是因为它是在tomcat上(解析jsp taglib慢,升级到4.1.10或resin就没有问题了)

>>1.服务引擎
可以只写一个Service,用于多个用途(Web,Application,Mobile,PDA,)

>>2.工作流引擎(做好工作流已经不错,还要做引擎,要多高深的思想和技术啊,我的嘴已经张大半天,没法合拢了)
目前open source的2个workflow engine的project之一,符合wfmc规范,我们用它写过2个Project,不是太好用,但是能完成大部分的用户需求.

>>4.实体引擎
Cool,可以减少采用DAO模式的编程工作,95%的数据实体化不需要写SQL语句,增加数据字段,数据表等,只用写xml定义文件,entity engine会自动帮你加上.(象CMP,嘿嘿),并且它的JTA做得非常好,

>>我敢说这东东一定是学校里的老师或学生搞出来的
Project Leader是2个有10年编程经验的人做的,不是老师,学生,他们是做IT质询公司的.

>>研究过ofbiz的说说看法
以上是我的看法,还有它的MVC做得非常好,比Structs要好太多(个人意见),M和V可以自己写handler,非常灵活

>>楼上提到的用户安全验证那块具体在哪里?
看一下实体引擎的定义文件

补充一点:
Util包下也有很多好用的:
如Cache Util,XML Util

他的MVC比struts好在哪里,我也觉得struts的MVC做得太复杂,几个servlet之间乱跳,你能详细讲讲吗?

他的Event是MVC的关键,如何理解他的Event?