权限模型
把权限模型划分为页面访问控制权限和数据权限
(
商业逻辑权限
)
。其中，页面访问控制权限主要在于控制页面是否可以被访问，比如，管理员可以访问权限设置页面。数据权限主要是指是否有操作某个数据的权限，比如说组织机构中的部分问题，一个部门应该只看到本部门的数据，这就是数据权限，这个应该在业务逻辑中控制，而不是页面中。
本权限模型专注于页面访问控制，不涉及数据操作权限。使用用户、角色、资源和操作来控制实际的页面访问。同时，区别于一般的页面权限模型，本模型采用细粒度的权限控制，可以控制到页面的具体操作，很不是整个页面不加区分。所以，这样就可以在一个页面放置多个操作，方便于用户，同时又不失安全性。
考虑到权限在实际中很少变动，使用数据库的冗余设计，还有数据缓存等来提高效率。
用户：
User
Id
、
name
用户角色表（
1
对多）：
Id
、
userID
、
roleID
角色
: Role
Id
、
name
、
description
、
defaultPage
（系统初始化时，使用的登陆页？）
权限
(Role-Resource-Operation)
：
Authority
Id
、
role
、
resource
、
resourceURL
（为效率考虑采用的冗余，等同
Resource
中的
url
，在实际验证中将使用该
url
来验证）、
operationID
、
operationName
（为效率考虑，采用冗余，等同
Operation
中的
name
，实际验证中使用该操作名称来做验证）
资源：
Resource
Id
、
name
、
description
、
url
操作：
Operation
Id
、
name(
一般应改为英文，对应方法的名字
)
、
description
BaseAction
中应该有一个
getMethodAuthMap
（），得到方法和可用操作的映射。如果映射中找不到，则直接使用该方法名当作操作名称。如果方法映射找到了，但是为空，这意味着该方法对于任何用户都是可以访问的，不要求验证。子类可以继承和覆盖该方法，来实现特殊的权限逻辑。
权限操作应该允许复制已有的权限来生成新的权限。
在前端控制器中设置已有的对于某个资源的操作，放到
hashtable
中，比如
auth
。对于页面，使用表达式语言
EL
来限制实际的逻辑，比如如下要求对于当前页面要有
delete
权限：
<c:if test=”auth.delete”>
</c:if>
同时，在整体页面中，使用
struts
的
dispathAction
来做分发，
url
形如
url?method=delete
在执行该方法之前，首先检查当前页面的这个权限
delete
，如果可以，则导向到正确的页面，否则导向到
accessDenied.do
页面（注意，该页面比较特殊，对于任何用户都应该是可以访问的，也就是前面的
getMethodAuthMap
返回为
NULL
）