单点登录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>120session-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">
        
        <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

 

转载于:https://www.cnblogs.com/notDog/p/5276643.html

你可能感兴趣的:(单点登录CAS使用记(七):关于服务器超时以及客户端超时的分析)