现在想到的是在Filter中做……
目标:通过配置来实现权限管理,在业务代码中无需再考虑权限问题
参考:类似tomcat的realm,在进到项目前,已经由容器判断了权限。权限管理通过配置来实现,在业务代码中无需再考虑权限问题。不足是,servlet规范中用URL Pattern配置访问级别,不够灵活
办法:在Filter中做权限判断?
我做了一个接口
boolean isUserHasPerm(String user, String url) |
MyFilter调用接口
|
isUserHasPerm接口已经初步实现,???现在的问题是Filter好像不是放权限判断的地方???,因为签名是这样的:
|
其中request 是ServletRequest, 不是HttpServletRequest,
response是ServletResponse,不是HttpServletResponse
这样就没有request.getSession().getAttribute("userinfo"),//得到权限判断的who要素
没有response.sendError() //这样没有权限,该如何处理?
???当然可以强行转换,tomcat下也不会cast错误,但始终不是个办法……???
-----------------------------------------------
另外,说明一下isUserHasPerm的实现
相关联的对象图
核心是ACL表,实际操作给出role,function,resource三要素,如果ACL表中有记录,说明可以访问,因为三要素唯一确定一条ACL记录(function通过resoure type和operate type确定)
优化后,剩三个表,User,Role,ACL(当然,因为User,Role是多对多,还要一个关联表)
ACL表包含四个字段:
Role, Component, Instance, OP(参考了PostNuke的权限设置)
Component就是resource type,
Instance就是resource
OP就是function
合并进Component和OP,而不是functionID的好处是,可以通过通配符来设置权限,比如设置一个全局的管理权限,只需要一条记录
|
另外,OP字段还可以等于DENY,有优先权,如果找到一条匹配的DENY记录,直接就是没有权限了。有了DENY,如果需要赋大部分权限,排除一小部分,也比较容易配置
isUserHasPerm的伪码
|
*注:从url中得到权限判断的要素,当然需要一些规则了,比如
category.do?op=add&id=1
表示component是category
op是add
instance是1
role当然是从session中拿