| [转帖]CAS 服务器端进入webflow前分析 | ||
上一篇:[整理]单点登录CAS，在Server端取得客户端IP，get client ip address |
||
| 添加日期：2014/3/6 14:13:31 | 快速返回 返回列表 | 阅读4474次 |
http://sjbrising.blog.163.com/blog/static/178298220201121112159226/ 首先，需要明确的是在xml中，各种各种配置的加载或者执行顺序 应该是context_pram，然后是listener，然后是filter，然后是action。 这个执行的顺序与各个配置在xml中出现的位置是没有关系的。但是，比如说filter执行的顺序与filter出现的顺序是有关系的。 <filter> <filter-name>CAS Client Info Logging Filter</filter-name> <filter-class>com.github.inspektr.common.web.ClientInfoThreadLocalFilter</filter-class> </filter> <filter> <filter-name>springSecurityFilterChain</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter> ClientInfoThreadLocalFilter这个类也没有太多的逻辑，就是获取了request.getLocalAddr(), request.getRemoteAddr()存放在ClientInfoHolder这个类中。 用DelegatingFilterProxy这个过滤器没有实现太多的逻辑，他的作用是将filter交给IOC容器管理而不是交给servlet容器管理 。这样做的好处是获得了Spring的依赖注入和生命周期的接口详情参考Spring文档 。 所以说，在过滤器中，没有放入太多的逻辑。 下面重点说下action的配置 <servlet> <servlet-name>cas</servlet-name> <servlet-class> org.jasig.cas.web.init.SafeDispatcherServlet </servlet-class> <init-param> <param-name>publishContext</param-name> <param-value>false</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>cas</servlet-name> <url-pattern>/login</url-pattern> </servlet-mapping> 这个类就是一个普通的springmvc的入口。 SafeDispatcherServlet其实就是有一个DispatcherServlet的引用，真正的转发工作还是DispatcherServlet去做的。 好了，，当浏览器中有/login的时候，就会进入DispatcherServlet来转发。转发到了哪呢？看cas-servlet.xml，在这个文件里，有这样的一个配置信息： <!-- spring webFlow定义（实现了流程控制，类似struts功能） --> <bean class="org.springframework.webflow.mvc.servlet.FlowHandlerAdapter" p:flowExecutor-ref="flowExecutor" p:flowUrlHandler-ref="flowUrlHandler" /> <bean id="flowUrlHandler" class="org.jasig.cas.web.flow.CasDefaultFlowUrlHandler" /> <!-- 根据工作流定义，生成一个执行器 --> <webflow:flow-executor id="flowExecutor" flow-registry="flowRegistry"> <webflow:flow-execution-attributes> <webflow:always-redirect-on-pause value="false" /> </webflow:flow-execution-attributes> </webflow:flow-executor> <!-- 注册一个工作流 id是子路径 为flow入口--> <webflow:flow-registry id="flowRegistry" flow-builder-services="builder"> <webflow:flow-location path="/WEB-INF/login-webflow.xml" id="login" /> </webflow:flow-registry> <webflow:flow-builder-services id="builder" view-factory-creator="viewFactoryCreator" expression-parser="expressionParser" /> 这里就是配置了一个webflow的定义。推测id就是一个入口标示。如果path匹配，则进入该流程。（webflow之前没接触到，这里先猜测一下）具体的流程定义在login-webflw.xml文件中。 好了，开始进入login-webflow流程。 进入login-wbeflow.xml,首先看到的是 <on-start> <evaluate expression="initialFlowSetupAction" /> </on-start> 这个就是所有进入流程之前比如执行的。看initialFlowSetupAction对应的类文件InitialFlowSetupAction 在这个类当中，有几个CookieGenerator。这里的有些东西比较值得借鉴，就是能尽量采用灵活配置的东西就不要硬编码。比如就是一个简单的 cookie的功能，就采用CookieGenerator，专门来管理cookie。这里CookieGenerator就不详细说了。 看doExecute函数，这个函数中的requestcontext参数，这个context不同于j2ee标准的context，在我的理解可能就是一个flow流程的临时性的context。存在flow的生命周期内，生命周期一结束，这个context就被销毁。 这里简单说一下webflow的应用场景，有的时候，可能用户一些属性需要跨越多个request，通常情况下，我们都是把它放在session中。但是session中放入过多的东西会引起很严重的性能问题，而且，在分布式系统当中，还可能会引发其他更严重的问题。这里webflow就应运而生了。他可以保存跨越多个请求的信息。请求结束，这些信息就可以被销毁。并且，可以支持跨多个请求的事务。等等吧。简单看了一点，理解的不深入。 这里比较核心的是在flowscope范围生成了一个service的对象。这个对象是根据http请求，转化成了其他的协议，比如cas，saml，OpenId等。默认支持的是cas和saml。 这个类的doExecute函数执行完毕后，正式进入登陆流程。 下一篇文章，我将详细探讨login的webflow。 本文版权所有 Bruce Bob，转载请注明出处。 本文链接地址：http://sjbrising.blog.163.com/blog/static/178298220201121112159226/ |
||
| 评论 COMMENTS | |
| 没有评论 No Comments. |
