单点登录CAS使用记（七）：关于服务器超时以及客户端超时的分析

我的预想情况

一般情况下，当用户登录一个站点后，如果长时间没有发生任何动作，当用户再次点击时，会被强制登出并且跳转到登录页面，

提醒用户重新登录。现在我已经为站点整合了CAS，并且已经实现了单点登录以及单点注销，那么当用户使用过程中，发生了超时的情况，

估计也是自动的强行登出了吧，而且可能其他部署了Cas的站点也跟着自动登出了。

我是这么猜想的。

那么实际情况到底是什么样的

首先先列出我自己开发过程中的遇到的一系列疑问：

1.Cas-Client超时后发生了什么？

2.Cas-Server超时后发生了什么？

3.Cas-Client与Cas-Server超时时间分别该怎么设置才比较好？

4.一个站点超时，其他站点集中被注销了吗？

下面来验证一下实际情况

1.Cas-Client超时后发生了什么？

Cas-Client客户端其实不需要额外做超时的配置，因为是在原有项目的web.xml中配置，说白了就是原项目的一部分，

所以以原项目设置的超时时间为准。

一般情况都是在web.xml中这么设置的：

    <session-config>
        <session-timeout>120</session-timeout>
    </session-config>

验证方法：

事前准备：

　　1.把webApp1的超时时间设置为1分钟，webApp2不做修改，超时时间为2小时，CAS-Server默认超时时间也是2小时

　　2.启动CAS-Server、webApp1、webApp2

　　3.分别登录webApp1、webApp2

验证动作：

　　2分钟后，我优先点击webApp1的网页，仿佛没有发生任何与超时相关的处理，依然可以正常访问所有页面。并没有强制跳转到登录页。我再点击webApp2的网页，也可以正常浏览。

　　又过了2分钟，我优先点击webApp2的网页，可以正常访问。再次点击webApp1，也可以正常访问。

验证结果：

　　1.webApp1虽然超时了，但是并没有被强制登出，依然可以正常访问。

　　2.webApp2完全没有受到webApp1的超时影响，也可以正常访问。

原因分析：

...编写中

 2.Cas-Server超时后发生了什么？

cas服务端超时应该主要指的是TGT(ticket granting ticket)超时，如果TGT时间到期，则需要进行重新登录。这里时间单位是毫秒，默认是两小时。

ticketExpirationPolicies.xml

    <bean id="grantingTicketExpirationPolicy" class="org.jasig.cas.ticket.support.TimeoutExpirationPolicy">
        <!-- This argument is the time a ticket can exist before its considered expired.  -->
        <constructor-arg
            index="0"
            value="7200000" />
    </bean>

验证方法：

事前准备：

　　1.CAS-Server默认超时时间也是2分钟，webApp1的超时时间设置为5分钟、webApp2的超时时间设置为10分钟。

　　2.启动CAS-Server、webApp1、webApp2

　　3.分别登录webApp1、webApp2

验证动作：

　　3分钟后，CAS-Server应该已经超时了，这时我访问webApp1，可以正常访问。访问webApp2，也可以正常访问。

　　6分钟后，CAS-server与webApp1应该都超时了，这时访问webApp1，页面被强制重定向到登录页面了。再访问webApp2，发现仍然可以正常访问。

　　11分钟后，webApp2页超时了，这时访问webApp2，页面就被重定向到登录页面了。

验证结果：

　　1.CAS-Server的TGT超时，并不会影响到页面的正常访问，也就是说TGT超时后，并没有主动的销毁客户端的Session。

　　2.只有当TGT超时后，并且客户端也超时了，这时候客户端才会主动向Cas-Server重新发起请求认证，然后发现TGT超时了，所以重定向回登录页面。

　　3.一个客户端超时并不会影响其他客户端的正常访问。

原因分析：

...编写中

 3.Cas-Client与Cas-Server超时时间分别该怎么设置才比较好？

从以上两个验证可以发现，一旦客户端通过了CAS-Server认证后，客户端就相当于完全独立了，即使再访问客户端的页面，客户端与CAS-Server之间也不在发生任何交互或者验证动作。

一直到客户端强制登出或者超时后，才会主动发起认证请求，CAS-Server才会被动的处理请求，判断是需要重定向还是重新认证通过。

也就是说，如果服务端超时时间设置的过短，并不会起作用，还是要等客户端超时后才行。

鉴于以上，客户端与服务端的超时时间应该设置为：

CAS-Server(TGT)超时时间  >=  Cas-Client的超时时间

4.一个站点超时，其他站点集中被注销了吗？

从之前的验证来看，一个站点超时，并不影响其他站点的正常访问。

(注：以上属于个人谬论，不保证正确性，有错误请予以批评指正，不喜请喷。)

---

单点登录CAS使用记系列：

• 单点登录CAS使用记（一）：前期准备以及为CAS-Server配置SSL协议

• 单点登录CAS使用记（二）：部署CAS服务器以及客户端

• 单点登录CAS使用记（三）：实现自定义验证用户登录

• 单点登录CAS使用记（四）：为登录页面加上验证码

• 单点登录CAS使用记（五）：cas-client不拦截静态资源以及无需登录的请求。

• 单点登录CAS使用记（六）：单点登出、单点注销

• 单点登录CAS使用记（七）：关于服务器超时以及客户端超时的分析

• 单点登录CAS使用记（八）：使用maven的overlay实现无侵入的改造CAS