cas入门之二十二：自动单点登出之后的问题

cas登录之后，产生tgt，当tgt过期之后，cas会自动消毁服务器端的tgt存根。如果开启自动登出（cas默认是开启的），则cas会向应用端发送
自动登出请求，应用接到这个请求，会消毁相应的session,这样就完成了自动登出。
之后用户，再次访问应用，就会出现页面假死，此时用户会刷新页面，
则会出现登录页面。用户输入用户名/密码直接登录就可以了。但是实际应用时
出现了很大的问题，那就是用户名/密码之后，页面一闪，页面没有任何反应，仍然显示在登录页面。
后台日志就是：
2014-07-31 08:47:28,269 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - <Audit trail record BEGIN
=============================================================
WHO: audit:unknown
WHAT: http://192.168.1.100/castest/index.jsp
ACTION: SERVICE_TICKET_NOT_CREATED
APPLICATION: CAS
WHEN: Thu Jul 31 08:47:28 CST 2014
CLIENT IP ADDRESS: 192.168.1.100
SERVER IP ADDRESS: 192.168.1.100
=============================================================


>


看了日志，我最初怀疑是登录页面没有抓到用户输入内容，但转念一想不对，如果没有抓取到用户名密码，为什么初始能够登录成功。
最初解决这个方法是，让用户关闭所有的浏览器，再打开，重新登录就可以了。这个事情困扰了我一段时间，决定解决它。


部署了测试环境，通过debug,发现并不是cas没有抓到用户输入内容，而是抓取到了。但是这个登录过程相当的缓慢，为什么呢？
因为我的测试环境，与正式应用一样，认证处理器有好几个。cas在认证的时候，会逐个处理，直到有一个成功为止。这个过程慢，我是知道的。
难道是因为它？如果是因为它为什么在关闭了浏览器用户就可以登录呢？
忽然想到了，这里cas-servlet.xml:
  <bean id="terminateWebSessionListener" class="org.jasig.cas.web.flow.TerminateWebSessionListener"
      p:serviceManagerUrl="${cas.securityContext.serviceProperties.service}" 
      p:timeToDieInSeconds="${login.flow.session.time2dieSeconds:2}" />
 
它的作用，就是在login.flow.session.time2dieSeconds　规定时间之内完成此次登录，如果完不成，则此次建立的session会被销毁。它其实是
调用HttpSession.setMaxInactiveInterval()方法，为session设置有效期。
我在实际应用中将其设为5秒，此次狠狠的将其改为50秒，并且修改了，相应的tgt过期时间，进行测试。当再次出现了登录页面是，输入用户名/密码，
登录一切顺利.
2014-07-31 08:47:36,883 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - <Audit trail record BEGIN
=============================================================
WHO: [username: test]
WHAT: supplied credentials: [username: test]
ACTION: AUTHENTICATION_SUCCESS
APPLICATION: CAS
WHEN: Thu Jul 31 08:47:36 CST 2014
CLIENT IP ADDRESS: 192.168.1.100
SERVER IP ADDRESS: 192.168.1.100
=============================================================


>
2014-07-31 08:47:36,883 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - <Audit trail record BEGIN
=============================================================
WHO: [username: test]
WHAT: TGT-4702-enhfFna6cfmh9UxG2YeirELfwjUV5zkdVGkWzOrWdde6DIxjUC
ACTION: TICKET_GRANTING_TICKET_CREATED
APPLICATION: CAS
WHEN: Thu Jul 31 08:47:36 CST 2014
CLIENT IP ADDRESS: 192.168.1.100
SERVER IP ADDRESS: 192.168.1.100
=============================================================


>


2014-07-31 08:47:36,893 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - <Audit trail record BEGIN
=============================================================
WHO: audit:unknown
WHAT: TGT-104-vUqI1v9xQrBLABQAiLCRZzIfrbhrCQIvvXjei73scrYo9oa3Dp
ACTION: TICKET_GRANTING_TICKET_DESTROYED
APPLICATION: CAS
WHEN: Thu Jul 31 08:47:36 CST 2014
CLIENT IP ADDRESS: 192.168.1.100
SERVER IP ADDRESS: 192.168.1.100
=============================================================


>
2014-07-31 08:47:36,897 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - <Audit trail record BEGIN
=============================================================
WHO: test
WHAT: ST-3865-f1QDJ5VjLBw12p9utpi1-ceair.118 for http://192.168.1.100/castest/index.jsp
ACTION: SERVICE_TICKET_CREATED
APPLICATION: CAS
WHEN: Thu Jul 31 08:47:36 CST 2014
CLIENT IP ADDRESS: 192.168.1.100
SERVER IP ADDRESS: 192.168.1.100
=============================================================


>


从日志输入，可以看出多了一步TICKET_GRANTING_TICKET_DESTROYED, 从而使此次的登录时间变长。我们只有加大登录的时间，才能解决登录的问题，在此记录
下来，希望下次遇到这样的问题，可以更快速的解决。