Acegi到底是怎么走的？(转载)
很早就听说过acegi了，但是当初只是下载了，并且网上找了点资料稍微看了一下。因为没有用到，所以也没有实践。最近忽然要用到了，才发现acegi的配置可不像想像中的那么简单。在网上找10篇相关文章，其配置也会有10样，各个不同，让人无可奈何。
至于acegi到底是干嘛的，它的一些最基础的介绍我这就不废话了。最近因为要配置acegi，所以没办法，只好按照一个参考并且分析了一下acegi的部分源代码，总算对acegi稍微有所理解了。下面把acegi内部流程分析如下：
acegi原理：
1 web.xml中配置filter类 org.acegisecurity.util.FilterToBeanProxy，
? 并设置targetClass 参数为 org.acegisecurity.util.FilterChainProxy
? 或者设置targetBean参数值为spring中配置的beanname
2 FilterToBeanProxy初始化中，获取targetBean的值，通过spring获取是否存在
? 如不存在，则通过targetClass参数构造FilterChainProxy.class并通过spring
? 获取配置为该class的所有beanNames,并将第一个bean设置为delegate.
3 当符合pattern配置的web请求来临时，则直接将直接filter操作转给delegate即
? FilterChainProxy类.
4 FilterChainProxy类也是Filter的实现类，它是通过spring注入方式生成的，
? 属性filterInvocationDefinitionSource的值在spring xml中配置.该值一般配置为字符串格式：
? CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
? PATTERN_TYPE_APACHE_ANT
? /**=httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,
?? securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,
?? anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
? 但是filterInvocationDefinitionSource属性是一个类，以上字符串如何转化为类的实例的呢？
? filterInvocationDefinitionSource extends ObjectDefinitionSource 类可以有多个
? ConfigAttributeDefinition，每个ConfigAttributeDefinition又可以包含多个Filter.
?
5 FilterChainProxy的doFilter方法中，先根据请求生成一个FilterInvocation类，然后根据该
? FilterInvocation类和4中配置的各种filter来得到处理当前请求的ConfigAttributeDefinition，
? ConfigAttributeDefinition中存储了所有与当前请求有关的filters.接着根据所有的filters生成
? 一个VirtualFilterChain类，VirtualFilterChain中顺序调用每个filter的doFilter方法，最后再
? 执行Chain.doFilter方法即执行实际请求的servlet
6 以下说明各个filter的执行过程,如果配置了多个filter则filter会按照配置顺序执行.
?6.1 HttpSessionContextIntegrationFilter 主要是在session中设置一个SecurityContext，而
?? SecurityContextHolder中也保存这个SecurityContext，而SecurityContext具备Authentication属性
?? 而第一次new SecurityContext的时候，Authentication是没有内容的。当chain.doFilter执行完毕
????????? 后执行SecurityContextHolder.clearContext().
??
?6.2 LogoutFilter 构造函数有两个参数:? 1.退出后转向的url;? 2.LogoutHandler
?? 如果请求不以"/j_acegi_logout"结束，则chain.doFilter，否则从6.1中的SecurityContextHolder
?? 中得到Authentication，并传入Authentication调用每一个LogoutHandler.logout方法。可以配置的
?? LogoutHandler有：
?? 6.2.1 TokenBasedRememberMeServices.logout就是把cookie删掉
?? 6.2.2 SecurityContextLogoutHandler.logout就是执行SecurityContextHolder.clearContext()
?6.3 AuthenticationProcessingFilter 需要配置authenticationManager属性：
?? authenticationManager->ProviderManager.它需要配置providers属性，可配置如下三个：
?????? 6311 AnonymousAuthenticationProvider.authenticate(Authentication) 比较HashKey是否相同
?????? 6312 RememberMeAuthenticationProvider.authenticate(Authentication) 比较HashKey是否相同
???? 以上两个如果HashKey不相同，则异常，相同则返回Authentication
?????? 6313 daoAuthenticationProvider-->DaoAuthenticationProvider：三个属性：
???? userDetailsService：必须设置项-->JdbcDaoImpl.通过username查询用户权限
???? userCache-->EhCacheBasedUserCache(cache:resourceCacheBackend,
???? cacheManager-->EhCacheManagerFactoryBean,resourceCache)
???? passwordEncoder-->Md5PasswordEncoder
?????? AuthenticationProcessingFilter执行时先获得客户端传入的用户和密码，构造Authentication实例
?????? UsernamePasswordAuthenticationToken，并通过ProviderManager验证是否正确。正确则转入成功页
?????? 面，否则错误页面。当配置了多个providers的时候，顺序验证，成功则不再调用下一个provider.
?????? DaoAuthenticationProvider.authenticate方法流程是：
??1 从参数authentication中获取userName
??2 从userCache中根据userName获取userDetails
??3 如果userDetails为空，则调用retrieveUser方法通过userDetailsService.loadUserByUsername
??? 获取userDetails. loadUserByUsername方法里面做了什么呢？
??? a:根据usersByUsernameQuery查询语句查询出用户信息List,并获得第一个记录.是User类
??? b:根据authoritiesByUsernameQuery查询语句查询出用户的角色信息,保存在GrantedAuthorityImpl
????? 类List中,GrantedAuthorityImpl是GrantedAuthority的实现类,getAuthority()方法将返回
????? role_name字段的值.然后将角色信息List转化成GrantedAuthority[]数组
??? c:构造new User[是UserDetails的实现类]返回。包含用户名、密码、角色GrantedAuthority[]数组。
??4 额外的additionalAuthenticationChecks。校验密码等
??5 用user置入userCache中
??6 返回UsernamePasswordAuthenticationToken[Authentication的实现类],包括角色信息
??7 这期间如果有异常，则抛出异常。因此最后返回了Authentication表明验明正身了。
?6.4 SecurityContextHolderAwareRequestFilter 将servletRequest包装成SavedRequestAwareWrapper类，然后
???? 再正常调用servlet
?6.5 RememberMeProcessingFilter 通过rememberMeServices.autoLogin方法获得Authentication(cookie而来)，
???? 再调用authenticationManager.authenticate方法，SecurityContext中再保存该Authentication
?
?6.6 anonymousProcessingFilter SecurityContext中保存一个AnonymousAuthenticationToken
?6.7 ExceptionTranslationFilter 属性有：
???? AuthenticationProcessingFilterEntryPoint[具备属性:loginFormUrl，forceHttps],
???? AccessDeniedHandlerImpl[具备属性:errorPage]
????
???? 该filter先调用chain.doFilter,并捕获该方法出现的异常。出现异常后，根据异常的
???? 类型做如下处理：
???? 如果是AuthenticationException或AccessDeniedException，则根据定义的loginFormUrl,将页面转向到该url
???? 否则执行accessDeniedHandler.handle方法,转到errorPage页面
?
?6.8 FilterSecurityInterceptor 该filter也是个重量级的filter，主要是个拦截器的作用。
? 该filter需要配置以下属性：
?? 6.8.1 authenticationManager 同6.3.1 校验密码并获取角色信息
?? 6.8.2 objectDefinitionSource
?? 6.8.3 accessDecisionManager-->AffirmativeBased[具备两个属性:allowIfAllAbstainDecisions,decisionVoters]
??而decisionVoters可以配置为
?????? 6821 RoleVoter 根据ROLE_来确定是否通过
?????? 6822 AuthenticatedVoter
??
?? FilterSecurityInterceptor.doFilter中做了什么呢？首先将requet,response,chian封装成FilterInvocation fi,
?? 然后执行以下 a:beforeInvocation,? b:fi.getChain().doFilter(...),? c:afterInvocation? 三个方法
???? A.beforeInvocation(FilterInvocation)方法返回值是InterceptorStatusToken,这个方法都做了什么呢?以下
?????? 1-6点说明了它的运行逻辑.
??1 从6.8.2中配置的objectDefinitionSource，调用其getAttributes(fi)方法.getAttributes(fi)方法中
??? 调用fi.getRequestUrl()得到url，然后调用objectDefinitionSource.lookupAttributes(url).
??? lookup方法就可以从数据库resource表中获取url对应的resource.
??2 将1中查询出来的resource与url逐一比较，如果匹配，则获得相应GrantedAuthority[]即roles
??3 将2中GrantedAuthority[]逐一getAuthority后根据','分隔拼凑成字符串authStr，并且new
??? ConfigAttributeEditor(),再调用ConfigAttributeEditor.setAsText(authStr)和
??? ConfigAttributeEditor.getValue()，将value强制转化成ConfigAttributeDefinition返回.
??? setAsText方法里面：new ConfigAttributeDefinition,再将authStr拆分成数组，逐一调用
??? addConfigAttribute方法将SecurityConfig(auth) add到ConfigAttributeDefinition中，再
??? setValue将ConfigAttributeDefinition设置为value.因此调用getValue的返回值可以强制转化为
??? ConfigAttributeDefinition类
??4 通过SecurityContextHolder.getContext().getAuthentication()获取Authentication.此处根据配置
??? 及Authentication.isAuthenticated()判断可能会再次调用 authenticationManager[6.8.1中配置]的
??? authenticate方法
??5 调用accessDecisionManager.decide(authenticated, FilterInvocation, ConfigAttributeDefinition)。
??? 下面分析一下AffirmativeBased这个decisionManager是如何decide的?
??? a: 对AffirmativeBased配置的每一个decisionVoter执行：调用voter.vote(Authentication,obj,
?????? ConfigAttributeDefinition)获取是通过还是denny还是弃权
??? b: 如果denny的数量>0,则异常不通过，如果有一个通过的则decide方法完成返回
??? c: 根据AffirmativeBased的allowIfAllAbstainDecisions("如果全部弃权则通过")属性，
?????? 如果false,则抛出异常
?????? RoleVoter.vote方法:从ConfigAttributeDefinition获取每一个ConfigAttribute.getAttribute(),
?????? 判断是否以"ROLE_"开头:
??????? 如是，检查Authentication中有没有与之匹配的，有则返回通过，无则返回denny
??????? 如不是，则返回弃权.
????? AuthenticatedVoter.vote方法:从ConfigAttributeDefinition获取每一个ConfigAttribute,调用
????? getAttribute(),判断是否是:
????? IS_AUTHENTICATED_FULLY：是则满足以下情况返回通过:
???????? **.既不是RememberMeAuthentication也不是AnonymousAuthenticationToken的实例
????? IS_AUTHENTICATED_REMEMBERED：是则满足以下任一情况返回通过:
???????? a*.Authentication是RememberMeAuthenticationToken的实例
???????? b*.既不是RememberMeAuthentication也不是AnonymousAuthenticationToken的实例
????? IS_AUTHENTICATED_ANONYMOUSLY：是则满足以下任一情况返回通过:
???????? a*.Authentication是AnonymousAuthenticationToken的实例
???????? b*.既不是RememberMeAuthentication也不是AnonymousAuthenticationToken的实例
???????? c*.Authentication是RememberMeAuthenticationToken的实例??????
????? 以上3种情况的判断中，如果依然没有return通过，则只要有一个Attribute()与以上3个相同，则返回
????? denny,否则弃权.
????
??6 根据FilterSecurityInterceptor是否配置了runAsManager，
??? 如配置了,则设置SecurityContextHolder中的Authentication为runAsManager.buildRunAs方法返回值
??? 并返回InterceptorStatusToken.contextHolderRefreshRequired=true
??? 如没有配置则返回InterceptorStatusToken.contextHolderRefreshRequired=false
???? B.fi.getChain().doFilter servlet-api的doFilter方法
???? C.afterInvocation(InterceptorStatusToken,returnObject)方法都做了什么呢?以下1-6点说明了它的运行逻辑
??1 如果InterceptorStatusToken==null,则返回returnObject
??2 token.isContextHolderRefreshRequired(),是则SecurityContextHolder中的Authentication设置为
??? token.getAuthentication()
??3 如果afterInvocationManager配置了，则调用afterInvocationManager.decide方法并返回decide的返回值.
注意:
?TokenBasedRememberMeServices.key? 与? RememberMeAuthenticationProvider.key 需要一致
?AnonymousProcessingFilter.key? 与?? AnonymousAuthenticationProvider.key? 需要一致
?
springside春天的的springside-2.0提供的bookstore例子中采用自定义的DBFilterInvocationDefinitionSource作为
?FilterSecurityInterceptor.objectDefinitionSource属性.它继承自AbstractFilterInvocationDefinitionSource类
?lookupAttributes(String url)方法被getAttributes(fi)调用.并且自定义了AcegiCacheManager和AcegiCacheManagerImpl
?类实现缓存。AcegiCacheManagerImpl有几个方法需要说明一下：
?1 initUserCache():获取所有用户以及用户角色，将角色转化为GrantedAuthority数组再构造UserDetails实例User置入
?? userCache
?2 initResourceCache():获取所有resource以及对应角色，将角色转化为GrantedAuthority数组再构造ResourceDetails
?? 实例Resource置入resourceCache.
?? 以上的cache采用了ehcache.cache元素Element类都采用了res_string作为key.
?lookupAttributes(url)中执行了如下过程:
?1 acegiCacheManager.getUrlResStrings()获取所有resStr.即查询resource表中res_type="URL"的所有记录的res_string字段
?2 比较所有res_string与url是否匹配，如果找到匹配项，立刻根据res_string获取对应的ResourceDetails接口即Resource实现类
?3 调用Resource.getAuthorities()将数组以,分隔转化为字符串并通过ConfigAttributeEditor类转化为ConfigAttributeDefinition
?? 返回给调用方.它又会被accessDecisionManager.decide方法作为参与调用,decide方法已经在前面介绍过了.
?
几个词汇：??????????????????? 对应数据库内容
Authentication:证明???? 用户表
Authority:权限????????????? 可能是role.每个角色的权限在acegi中描述为资源resource.而资源是通过url来区分的.
Credential:信任状????? 密码
Principal:负责人??????? 用户名
因此重点就在于 role,resource等表数据内容的编制了！！
?
?
?
?
