在CAS中MVC的控制主要是使用的spring MVC来实现的。但是,在登录过程中,因为有点类似于工作流的性质,所以,采用了一个轻量级的工作流框架,就是spring 的weflow。下面,我们就CAS如何采用webflow控制登录流程进行分析。
想深入理解webflow工作原理的读者需要参考官方的webflow2.21版本的reference。
好了,话不多说,开始CAS认证流程之旅。
用户请求如何进入认证流程的
用户一开始输入http://localhost:8080/CASServer 的时候,默认是回去访问 index.jsp的。我们看一下index.jsp,里面的内容非常简单。
final String queryString = request.getQueryString(); final String url = request.getContextPath() +"/login" + (queryString!= null ?"?" + queryString : ""); response.sendRedirect(response.encodeURL(url));
这里进行的处理就是将用户的请求重定向到CAS认证中心的 /login 路径下。在上一章中,我们已经知道,该路径我们是由 名为 CAS 的servlet,也就是org.jasig.cas.web.init.SafeDispatcherServlet 进行处理的。我们进入该servlet看一下他是如何进行处理的。
进入该servlet中,我们看到,他继承自 HttpServlet,也就是说他只是一个普通的servlet。该servlet持有一个DispatcherServlet 属性delegate。这同struts的处理方式如出一辙。都是通过一个代理类来进行处理请求的。
该类的初始化也仅仅是调用代理类delegate的初始化。Service函数很仅仅是调用delegate的service函数。
看来,DispatcherServlet类才是处理请求的关键类。我们看到DispatcherServlet类的完整路径是
org.springframework.web.servlet.DispatcherServlet
这里,也就是将请求交给了spring MVC处理了。(关于spring mvc,参考我其他的关于spring 的源码分析文章)。
Webflow与Spring MVC集成
Spring MVC核心配置文件是cas-servlet.xml。在该文件中,webflow将与springMVC进行集成。
这里有一个问题,就是spring何时开始加载cas-servlet.xml文件的呢?
原来,在初始化DispatcherServlet的时候,会自动加载 servlet-name+“-servlet.xml”文件。所以,cas-servlet.xml是自动加载的,不需要在配置文件进行配置。(参见关于springMVC的文章)
交给spring MVC之后,spring MVC又将请求交给了 webflow处理。下面是webflow同spring MVC的结合:
<!-- 根据工作流定义,生成一个执行器 --> <webflow:flow-executorid="flowExecutor"flow-registry="flowRegistry"> <webflow:flow-execution-attributes> <webflow:always-redirect-on-pausevalue="false"/> </webflow:flow-execution-attributes> </webflow:flow-executor> <!-- 注册一个工作流 id是子路径 为flow入口对login的请求交由login-webflow.xml定义的处理器进行处理--> <webflow:flow-registryid="flowRegistry"flow-builder-services="builder"> <webflow:flow-locationpath="/WEB-INF/login-webflow.xml"id="login"/> </webflow:flow-registry> <webflow:flow-builder-servicesid="builder"view-factory-creator="viewFactoryCreator"expression-parser="expressionParser"/>
在该文件中,我们可以看到上面的配置项。这就是将webflow框架作为spring MVC的一个节点来进行配置。
webflow:flow-registry节点就是注册了一个webflow流程,该流程的入口,也就是ID=“login”。这样,交给springMVC的请求路径如果是login的,则有springMVC交给webflow处理。
在webflow中,会定义一些视图,这些视图都是以view=”XXX”的形式存在的。那么XXX又是如何找到对应的页面呢??看flow-builder-services节点,我们会发现有个view-factory-creator属性,该属性就定义了视图解析工厂。
该视图解析工厂是由视图解析器组成的。这里只定义了一个视图解析器,就是viewResolvers。该视图解析器是springFramework中的ResourceBundleViewResolver的一个实例,该类可以通过basenames属性,找到value值对应的properties属性文件,该文件中式类似ke=values类型的内容,正是该文件将jsp文件映射成视图名称。
至此,springMVC与webflow已经集成完毕。
Webflow配置文件及源码分析
在WEB-INF文件夹下的login-webflow.xml是登陆流程的主要配置文件。在该文件中,定义了用户登录的整个处理流程。
首先,配置文件中的 on-start标签定义了用户第一次进入流程中的预处理动作。该标签对应spring中的id为initialFlowSetupAction的bean。查看该bean(InitialFlowSetupAction)的代码。该类需要继承自AbstractAction,AbstractAction方法是org.springframework.webflow.action包中的类。是webflow中的基础类。该类中的doExecute方法是对应处理业务的方法。就犹如servlet中的service方法一样。该方法的参数是RequestContext对象,该参数是一个流程的容器。该方法从request中获取TGT,并且构建一个临时的service对象(不同域注册的service,详情见接入系统管理)。并且,将TGT和service放在FlowScope作用域中。
流程的初始化完毕之后,就开始一系列的判断了。也就是进入decision-state节点。这些节点是依次执行的。
<!--检查flow中是否存在TGT如果存在,存在进入hasServiceCheck,为空进入gatewayRequestCheck--> <decision-stateid="ticketGrantingTicketExistsCheck"> <if test="flowScope.ticketGrantingTicketIdneq null"then="hasServiceCheck"else="gatewayRequestCheck"/> </decision-state> <!-- 主要是CS结构使用gatewat,暂时不研究--> <decision-stateid="gatewayRequestCheck"> <if test="externalContext.requestParameterMap[‘gateway‘]neq ‘‘ && externalContext.requestParameterMap[‘gateway‘] neqnull && flowScope.service neq null" then="gatewayServicesManagementCheck"else="viewLoginForm"/> </decision-state> <!-- 存在TGT,说明用户已经登陆,测试flow中service是否为空,不为空,进入renewRequestCheck,为空,进入viewGenericLoginSuccess--> <decision-stateid="hasServiceCheck"> <if test="flowScope.service!= null"then="renewRequestCheck"else="viewGenericLoginSuccess"/> </decision-state> <!-- 用户已经登陆,且请求参数中存在service判断请求中是否存在‘renew‘参数,如果renew参数为空或者没有内容,那么,进入viewLoginForm,否则进入generateServiceTicket renew参数和gateway参数不兼容。renew参数将绕过单点登录。也就是说即使用户登录了,还将要求用户登录。(等你妹啊,人家都登录了,凭什么还要让人家再登录一次) --> <decision-stateid="renewRequestCheck"> <if test="externalContext.requestParameterMap[‘renew‘]neq ‘‘ && externalContext.requestParameterMap[‘renew‘] neqnull"then="viewLoginForm"else="generateServiceTicket"/> </decision-state> <decision-stateid="warn"> <if test="flowScope.warnCookieValue"then="showWarningView"else="redirect"/> </decision-state>
对应的dicision-state走完之后,如果不存在TGT,其实就会进入voiwLoginForm节点。该节点是一个view-state类型的,这也就是说明该节点是一个页面,view=“casLoginView”属性定义了该view对应的页面是“casLoginView”。这个视图会被spring的视图解析器解析成/WEB-INF/view/jsp/default/ui/casLoginView.jsp页面。用户这时候就能看到一个登陆界面了。
需要注意的是,用户看到的登录界面中,会有hidden类型的一个lt参数:
<inputtype="hidden" name="lt"value="${flowExecutionKey}" />
该参数可以理解成每个需要登录的用户都有一个流水号。只有有了webflow发放的有效的流水号,用户才可以说明是已经进入了webflow流程。否则,没有流水号的情况下,webflow会认为用户还没有进入webflow流程,从而会重新进入一次webflow流程,从而会重新出现登录界面。
用户点击登录之后,提交到realSubmit节点。该节点执行的是authenticationViaFormAction.submit方法,在该方法中,将会验证用户的认证信息是否正确。验证成功之后,跳转到sendTicketGrantingTicket,在这里,将生成TGT,然后,进入serviceCheck,在serviceCheck中,将会验证flowScope作用域中是否存在service,如果存在,则进入generateServiceTicket,否则进入登录成功页面。在generateServiceTicket中,也将生成ST,同时检查是否有警告信息,然后进行重定向到用户最开始请求的地址。
至此,springMVC与webflow整合以及登录整个流程已经讲解完毕。
这里讲解的比较粗略。后续可能会较详细的写一下webflow的工作原理。另外,如果对于自定义登录流程如何处理,将会在特殊场景的解决方案中给出。