老生长谈：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的配置文件信息不能轻易变动（虽然在生产型系统中变动的可能性不会很大），还有个缺点就是不方便以可视化的方式进行管理。

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

用户、角色、资源、权限、模块
不知道为何多出一个模块来

模块的加入是为了对应系统各个模块菜单，可以粗粒度地对用户可访问资源进行控制。比方说如果系统存在客户管理、销售管理、财务管理，如果一个角色没有访问财务管理模块的权限。那么只要不将该模块配给该角色，那么它在界面上就不会显示该模块菜单。

xml权限啊....那是在java分工中还含有
布署工程师这个职业时老皇历了....

是呀，所以我才犹豫啊！

只是如果这样结合Struts，至少资源跟权限部分的配置信息我就可以省略掉了。

建议不使用XML文件存在，放数据库里查询方便，在XML里就比较麻烦了，例如，你要列举出某个资源都有哪些角色甚至哪些用户有对应的权限时，你就傻眼了。

我把权限分两种：
1.操作权限
2.数据权限

操作权限UI化——与UI组件结合
数据权限灵活化——不用上下级关系来确定数据权限

可以两者配合着用，启动时把XML导入到数据库中，毕竟在开发时，一些配置写在XML里，比在数据库中来配置要方便。

有考虑过这种方案，可是难道每次重启服务都要把表删除，然后重建？