老生长谈：B/S权限设计（基于Struts 2.*）

这是个老话题了，随便GOOGLE或者百度都可以找到一大堆。现在的权限控制基本上都是基于RBAC的，在这里我是基于RBAC与Struts2.*，可能还有些没有完善的地方，提出来与大家讨论一下。

 

我们知道，权限一般分为操作权限跟数据权限，这里讨论的只是操作权限。其实与其说是讨论，倒不如说是讨教，因为我这边已经有几个方案（主要是持久化这部分），但是一直拿捏不定。

 

第一种方案：

1.跟大多数的设计一样，分为用户、角色、资源、权限、模块。其中：资源代表的是Struts 2.*中的Action类，权限则是每个Action中的操作方法。例如，PassportAction有这么几个方法：login、logout、regist。PassportAction就是一个资源，而login、logout、regist则代表一个个权限。同时，权限还有一个属性表示是否为默认权限，以减少权限的配置。

 

2.模块则是与页面相关的资源，比方说系统有一个销售管理的模块，在程序中可能是webapp/${工程名}/application/sale/SaleManage.jsp的页面。在这里，我将模块设计成树形结构，也就是由上下级关系。用户登录后，系统将根据用户持有的模块信息，将所有的模块显示出来。

 

3.角色则是一组权限跟一组模块的组合。

 

4.用户则可以同时持有多组角色。

 

然后是权限验证，因为采用的Struts2.*，可以使用拦截器的方式来实现。大概的思路是这样的，拦截器可以很容易就获取每次请求调用的Action信息，可以根据这些信息从数据库找到相应的资源（当然你也可以做Application级别的缓存）和方法信息。这样就可以得到一个判断结果。至于模块的设计是为了在用户登录系统时可以直接输出模块信息（模块树）。

 

然后是持久层的设计，在这种方案中我采取的是数据库来保存数据。分别为T_Resource、T_Privilege、T_Module、T_Role、T_Role_Privilege_Link、T_Role_Module_Link、T_User_Role_Link。

 

Java类的设计就不说，相信大家能做得比我更好。

 

第二种方案：

设计思想跟第一种方案差不多。只是Resource不再独立成一个类，Privilege则变成一个Url，其中包含两个属性：NameSpace跟ActionName。同时，Privilege不在独立存储，即根据每次请求的Action与method组合而成。至于Role，用xml方式来存储。一种角色用一个Xml存储，xml文件名则是角色名称。

 

比方说Sale.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Role PUBLIC "Role" "role.dtd" >
<Role>
	<PrivilegeSet>
		<Privilege>/login</Privilege>
		<Privilege></Privilege>
	</PrivilegeSet>
	<ModuleSet>
		<Module></Module>
	</ModuleSet>
</Role>

 这样我就可以再系统启动的时候便解析这些角色配置文件，然后将角色实例缓存下来（当然，缓存下来的可不仅仅只是角色，还有权限跟模块），然后以角色名（如Sale）为key查找，权限、模块的缓存也相似。

 

这种方式的一个好处就是，配置完Struts以后权限也配置完成，权限部分不容易出错，而且容易备份，但是一般角色超过某个数量的时候，维护起来相当麻烦，而且要保证Struts的配置文件信息不能轻易变动（虽然在生产型系统中变动的可能性不会很大），还有个缺点就是不方便以可视化的方式进行管理。

评论

1 楼 hsbljyy 2009-09-10  

其实还有想过将Module也合并到Privilege中，因为Module严格说起来也是一种Resource，也可以算是一种权限，然后在Privilege中增加一个isModule的属性进行控制，后来觉得这种方案更烂就直接放弃了。