锁定老帖子 主题:Spring Security学习笔记
精华帖 (0) :: 良好帖 (5) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2011-01-24
最后修改:2011-01-25
看了一个星期的Spring Security源码,应该说对控制URL级别的访问控制的认识是有80,90%了,这里把自己的一些记录给贴出来,分享是一方面,保存也是一方面。好了不说了,看下面具体分析了: URL资源控制访问处理流程: 数据准备 ( 顺序不一定是按照下面来的 ) : 第一步:用户登录的时候根据用户名从数据库中查出用户所具有的 GrantedAuthority[] 信息,将它复制给 Authentication 对象 (Authentication 中有一个 GrantedAuthority[] 的属性 ) ,权限信息都封装成了 GrantedAuthorityImpl 的对象。 简单的描述一下关系就是: 当然存的是 GrantedAuthorityImpl 对象,也就是说 ROLE_ADMIN 这些值都被进行封装了一下。
看一下顺序图:
第二步:从数据库中查出资源与权限的对应信息,以 map 的形式保存,比如像这样: 注意从数据库中取出数据的第一次封装就是封装成下面的这种形式,权限都是以 ”,” 分隔的。 接下来进行第二步封装: 对 resourceMap 进行再次处理,主要是对上面的权限信息封装成 ConfigAttributeDefinition 对象,但是上面都是以 ”,” 分隔的字符串的形式,而我们查看 API 发现 ConfigAttributeDefinition 虽然有这样的构造函数,但是要求的是 a single attribute : public ConfigAttributeDefinition
(String
attribute)
Creates a ConfigAttributeDefinition containing a single attribute 这时候我们就交给一个 ConfigAttributeEditor 的类进行处理: 它里面有这个方法: setValue ( new ConfigAttributeDefinition(StringUtils.commaDelimitedListToStringArray (s))); 看到这个没有 StringUtils.commonDelimitedListToStringArray(s) 没有,就用了这个。这样我们就通过再次构造得到了另外一个 Map requestMap ,它存的就是这样的形式:
当然对以 map 中的 KEY ,也进行了封装处理,它们都被封装成了 RequestKey 对象的形式。 再通过提供 UrlMatcher 和 RequesetMap 我们构造了一个 DefaultFilterInvocationDefinitionSource 对象。 在这里说一下,其实 ConfigAttributeDefinition 中保存的配置信息都存在一个 List 当中,而 List 当中存储的是 SecurityConfig 对象,而 SecurityConfig 对象是 ConfigAttribute 类型的。也就是所这样形式的配置信息: ROLE_ADMIN,ROLE_USER 被处理成 String[] 形式存储到了 ConfigAttribute 对象中, ConfigAttribute 对象再存在 ConfigAttributeDefinition 对象的 List 属性中。
前期的准备工作算是做好了,现在进行相关处理了,这里我们主要使用的是 FilterSecurityInterceptor 来处理,我们给 FilterSecurityInterceptor 提供了我们已经准备好的这些东西,除了上面这两个以外还提供了一个 AccessDecisionManager( 决策管理者 ) ,这个是决定我们是否可以访问资源的决策器,当然使用的资源就是我们上面提供了这两个东西。 当请求达到的时候,我们通过 FilterSecurityInterceptor 拦截到了请求,构造成了 FilterInvocation 对象,然后进行下面的处理: 第一步,通过这个 FilterInvocation 来取得 ConfigAttributeDefinition 对象,上面已经讲到对于资源和权限是以 map 形式存在的,并且权限信息是封装成了 ConfigAttributeDefinition 对象, ConfigAttributeDefinition attr=objectObjectDefinitionSource().getAttributes(object); 通过 DefaultFilterInvocationDefinitionSource 类中的下面三个方法的顺序调用,我们就可以取得 URL 所对应的 ConfigAttributeDefinition 对象。
第二步:获得认证对象 : Authentication authenticated=authenticateIfRequired() ,对于认证对象的获得这里就不再复述了文档中已经分析了。 现在 Authentication 和 ConfigAttributeDefinition 都已经准备好了,就可以进行决定是否可以访问了,这叫个 AccessDecisionManager 进行处理。 第三步:决策访问控制: accessDecisionManager.decide(authentication,filterInvocation,configAttributeDefinition); 这里提供一种处理方式:
这里要说明一下关于没有权限之类的处理, Spring Security 是通过异常处理来实现的,捕捉异常根据异常信息跳转页面。
这里只对URL资源控制进行分析了,如果我理解错了,希望大家给我改正。
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2011-01-25
最后修改:2011-01-25
图片没显示出来
文档不错 打印出来 公车上看 |
|
返回顶楼 | |
发表时间:2011-01-25
最后修改:2011-01-25
重新弄了一下,图出来了,文档中也有这些描述
|
|
返回顶楼 | |
发表时间:2011-01-25
Spring Security3已经有些变动了,org.springframework.security包下的类都转移到org.springframework.security.core了,Authentication 中的属性也变为Set<GrantedAuthority>了。
|
|
返回顶楼 | |
发表时间:2011-01-26
多谢lz,学习一下先。
|
|
返回顶楼 | |
发表时间:2011-01-26
spring security3.1.x跟3.x以及之前的版本也有变化的。当时我整权限这块整了好久,现在终于整出了。抽空的时候我也整理下笔记出来。
|
|
返回顶楼 | |
发表时间:2011-01-26
上传一个例子 我们看看
|
|
返回顶楼 | |
发表时间:2011-01-26
写得不错
之前的一个很小的项目里面用到spring security 如果LZ早写这文章就可以减少点我用在学习spring security的时间了,呵呵 因为我这个小项目权限那块用的是User<-->Role<-->Authority,所以spring security实际上只会关心User拥有什么Authority,反而没有Role这个概念,这样理解应该没错吧? 不知spring security是不是认为大多数系统只会用到User<-->Role这样的结构,所以权限的控制判断默认是ROLE_XXX这样,个人觉得看起来很怪 |
|
返回顶楼 | |
发表时间:2011-01-27
感谢楼主,最近也想找本书 下载到 psp 里面,看,,正好啊
不错 不错,顶 |
|
返回顶楼 | |
发表时间:2011-01-27
最近做项目也用到了Spring Security,好好学习一下,自己一个人做!
|
|
返回顶楼 | |