Acegi源码研究(五):七剑下天山
在Acegi初体验及初剖解(http://rmn190.javaeye.com/blog/332711)里, 通过对web.xml和applicationContext-acegi-security.xml的跟踪,我们得出被Acegi拦截下的请求最终交到了filterInvocationDefinitionSource设置下的几个Filter的实现类来处理惩罚. 它们是怎么处理惩罚这个请求的呢? 在Acegi(三): Acegi？ Who are you? ,我们传闻江湖中有"七剑", 但这么久了"七剑"怎么还 没露面呢? 这篇博客中我们将看到下天山的"七剑".
首先我看下都有哪些Bean参于了Acegi的守卫事情, 如下图所示:
上面是静态的界说, 再看下图的动态挪用图:
这里团结着上图,我们随着欣赏器发出的请求走一遍.
Step1: 对上就上图中数字1,这里欣赏器发出一个请求.
Step2: Web处事器,我们这里的Tomcat接管到Step1发来的HTTP请求, 把内里的信息抽取出来,组装成一个Request 工具, 同时Tomcat也生成了一个Response工具,这样接下的Request穿过的Filter都有时机来修改这个Response工具了, 也正是Acegi抓住了这个时机操作Filter来改变Response里的值到达掩护我们系统的浸染.这里Request达到图中的"Filter chain proxy", 我们还记得web.xml中设置的" FilterToBeanProxy "及基设置参数 FilterChainProxy(targetClass的值), 再看Bean图中的 filterChainProxy,这里我们动态地感受到这个 filterChainProxy的存在了.通过设置中的" /**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor" 一句我们汇报 filterChainProxy 当Request来时,都有哪些Filter处理惩罚这个Request.
Step3/Step4: filterChainProxy挪用filterChain中的第一个Filter,也就是 httpSessionContextIntegrationFilter . 这个httpSessionContextIntegrationFilter 是 HttpSessionContextIntegrationFilter类的实例, 这个类正是"七剑"之一. 从它的名字上,我们也隐隐约约地感受到了点什么: 把Context integrate 到HttpSession中? 对的, 在HttpSessionContextIntegrationFilter的 doFilter要领里Acegi从HttpSession中得到 SecurityContext 工具(或没有的话新建个), 随后再把这个 SecurityContext存放到 SecurityContextHolder中, 很自然嘛, SecurityContextHolder 就是用来放 SecurityContext的. 做了这些处理惩罚后, httpSessionContextIntegrationFilter通过 chain.doFilter要领将执行权交给下一filter.
我们例子中下一个filter就是 authenticationProcessingFilter,它是 AuthenticationProcessingFilter的实例,看它名字里有Authentication跟"七剑"中的 Authentication有干系? 不错, authenticationProcessingFilter类中有一个 requiresAuthentication要领, 顾名思义,它是看当前的Request是否是用来做验证的,也就是说是否是登录的. 这就用到了Bean设置 authenticationProcessingFilter里属性, 看Acegi的源码可以获得验证. 接下来, 在要领 attemptAuthentication中Acegi从Request中取出 username和 password组建一个 Authentication 工具, 再由设置中的 authenticationManager来加以验证,若"灯号"没对上的话, 就有一个 AuthenticationException异常抛出, authenticationProcessingFilter catch住这个 AuthenticationException,再通过 sendRedirect要领在欣赏器中指向 authenticationFailureUrl的值" /login.jsp?login_error=1 ". 若"灯号"对上了,将通过要领 successfulAuthentication重定向到 defaultTargetUrl指定的页面, 同时Acegi把对上"灯号"的 Authentication工具通过要领 SecurityContextHolder.getContext().setAuthentication存放到 SecurityContext中,以备后用.
Step5/Step6: Acegi将Request(虽然尚有Response)交给下一个Fillter, 我们例子中是 filterInvocationInterceptor(实际上交给了 exceptionTranslationFilter,这里我们为了接头的利便,假定交给了 filterInvocationInterceptor ),这个filter再从SecurityContextHolder中取出SecurityContext,再取出内里的已经对上"灯号"的Authentication工具(此工具在本例中实际上是封装了users.properties里这样的" [email protected],ROLE_TECHNICIAN "键值对), 再把这个 Authentication工具交给当前bean中设置的 accessDecisionManager属性以抉择 Authentication是否能会见它想会见的资源.经 accessDecisionManager"研究"后发明可以会见,此时Acegi即将Request/Response交给我们系统里设置的相应要领(如Struts里设置的某一method).若"研究"时发明没权限,则以异常的方法交给上面提到的 exceptionTranslationFilter,这个filter再重定向到 loginFormUrl指定的URL上.
到这步调已走完了, 那怎么没看到"七剑"中的另三剑呢? 它们是 GrantedAuthority , UserDetails , Us erDetailsService . 实际上它们在filterInvocationInterceptor顶用到了, 不外其时为了接头的利便,并没有写出来. 是这样的, 在抉择一个 Authentication是否可以会见它想要的资源时, accessDecisionManager会从 Authentication里 挪用getAuthorities获得它的 GrantedAuthority[] , 再将它们与通过Us erDetailsService
#p#分页标题#e#
获得的 UserDetails 工具里要领返回的GrantedAuthority[]一一较量, 若在较量进程中发明有个对应上了, 就暗示有权会见,不然即无权. 这里所阐述的进程正是上面 accessDecisionManager所做的"研究".
好了,至此, 我们通过跟踪请求的来龙去脉把 applicationContext-acegi-security.xml设置中的Filter走了一遍,更重要的是走filter时,我们与Acegi江湖里的鼎鼎台甫的"七剑"有了短暂但优美的打仗.
