//当我们用权限框架控制登录超时跳至某一个页面时主页面都没什么问题;iframe会在当前窗口下再开一个会话很显然这不是我们想要达到的效果
在登录页中加入此判断即可
1 $(function(){ 2 3 //iframe session超时判断URL是否为顶级窗口 4 if (window.top!=null && window.top.document.URL!=document.URL){ 5 window.top.location= document.URL; 6 } 7 8 })
//当我们用权限框架控制登录超时跳至某一个页面时主页面都没什么问题;iframe会在当前窗口下再开一个会话很显然这不是我们想要达到的效果
在登录页中加入此判断即可
1 $(function(){ 2 3 //iframe session超时判断URL是否为顶级窗口 4 if (window.top!=null && window.top.document.URL!=document.URL){ 5 window.top.location= document.URL; 6 } 7 8 })
转载于:https://www.cnblogs.com/XinHuai/p/6824903.html
预想情况
一般情况下,当用户登录一个站点后,如果长时间没有任何动作,当用户再次单击时,会被强制登出并跳转到登录页面,提醒用户重新登录。
现在我已经为站点整合了CAS,并且已经实现了单点登录以及单点注销,那么当用户使用过程中,发生了超时的情况,估计也是自动强行登出了吧,而且其他部署了CAS的站点也跟着自动登出。
上面的是猜想,那么实际情况到底是什么样的?疑问
- CAS-Client 超时会发生什么?
- CAS-Server超时会发生什么?
- CAS-Client与CAS-Server超时时间分别该怎么设置比较好?
- 一个站点超时时,其它站点集中被注销了吗?
验证
1. CAS-Client 超时会发生什么?
CAS-Client客户端超时时间其实就是项目session的有效时间,默认:30分钟,(springboot2.x)可修改配置:
server: servlet: session: timeout: 1800s
验证方法:
a. 事前准备:
- 把webApp1的超时时间设置为1分钟,webApp2的超时时间设置为2小时,CAS-Server默认超时时间也是2小时
- 启动CAS-Server、webApp1、webApp2
- 分别登陆webApp1、webApp2
b. 验证动作:
2分钟后,我优先单击webApp1的网页,仿佛没有发生任何与超时相关的处理,依然可以正常访问所有页面。并没有强制跳转到登录页。我再单击webApp2的网页,也可以正常浏览。
又过了2分钟,我优先单击webApp2的网页,可以正常访问。再此单击webApp1,也可以正常访问。
c. 验证结果:
- webApp1虽然超时了,但是并没有被强制登出,依然可以正常访问。
- webApp2完全没有收到webApp1的超时影响,也可以正常访问。
2. CAS-Server超时会发生什么?
cas服务器超时主要指的是TGT(ticket granting ticket)超时,如果TGT时间到期,则需要进行重新登录。默认是2小时。这里单位是秒
#tgt.timeToKillInSeconds是指在用户没有对系统进行任何操作的情况下,7200秒之后,也就是两个小时之后TGT会过期。过期之后需要重新登录操作。 cas.ticket.tgt.time-to-kill-in-seconds=7200
验证方法:
a. 事前准备:
- CAS-Server超时时间设置为2分钟,webApp1超时时间设置为5分钟,webApp2超时时间设置为10分钟。
- 启动CAS-Server、webApp1、webApp2
- 分别登录webApp1、webApp2
b. 验证动作:
3分钟后,CAS-Server应该已经超时了,这时我访问webApp1,可以正常访问。访问webApp2,也可以正常访问。
6分钟后,CAS-server与webApp1应该都超时了,这时访问webApp1,页面被强制重定向到登录页面了。再访问webApp2,发现仍然可以正常访问。
11分钟后,webApp2页超时了,这时访问webApp2,页面就被重定向到登录页面了。
c. 验证结果:
CAS-Server的TGT超时,并不会影响到页面的正常访问,也就是说TGT超时后,并没有主动的销毁客户端的Session。
只有当TGT超时后,并且客户端也超时了,这时候客户端才会主动向Cas-Server重新发起请求认证,然后发现TGT超时了,所以重定向回登录页面
3.一个客户端超时并不会影响其他客户端的正常访问。
3. Cas-Client与Cas-Server超时时间分别该怎么设置才比较好?
从上面两个验证可以发现,一旦客户端通过CAS-Server认证后,客户端就相当于完全独立了,即使再访问客户端的页面,客户端与CAS-Server之间也不会再发生任何交互或者验证动作。
一直到客户端强制退出或者超时后,才会主动发起认证请求,CAS-Server才会被动处理请求,判断是需要重定向还是重新认证通过。也就是说,如果服务器超时时间设置的过短,并不会起作用,还是要等客户端超时才行。
鉴于以上结论,客户端和服务器的超时时间设置应该为:
CAS-Server(TGT)超时时间 >= CAS-Client的超时时间4. 一个站点超时,其他站点集中被注销了吗?
从之前的验证来看,一个站点超时,并不影响其他站点的正常访问。
总结
CAS-Server和CAS-Client超时结果图:
CAS-Server | webApp1 | webApp2 | 是否重新登录 |
---|---|---|---|
未超时 | 未超时 | 未超时 | webApp1、webApp2都不会重新登录 |
未超时 | 超时 | 未超时 | webApp1、webApp2都不会重新登录 |
未超时 | 超时 | 超时 | webApp1、webApp2都不会重新登录 |
超时 | 超时 | 未超时 | webApp1会重新登录、webApp2不会重新登录 |
超时 | 未超时 | 超时 | webApp1不会重新登录、webApp2会重新登录 |
超时 | 超时 | 超时 | webApp1会重新登录、webApp2会重新登录 |
我的预想情况
一般情况下,当用户登录一个站点后,如果长时间没有发生任何动作,当用户再次点击时,会被强制登出并且跳转到登录页面,
提醒用户重新登录。现在我已经为站点整合了CAS,并且已经实现了单点登录以及单点注销,那么当用户使用过程中,发生了超时的情况,
估计也是自动的强行登出了吧,而且可能其他部署了Cas的站点也跟着自动登出了。
我是这么猜想的。
那么实际情况到底是什么样的
首先先列出我自己开发过程中的遇到的一系列疑问:
3.Cas-Client与Cas-Server超时时间分别该怎么设置才比较好?
下面来验证一下实际情况
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
转载于:https://www.cnblogs.com/notDog/p/5276643.html
现象
一些内部管理系统,Java的程序部署到服务器之后,由于并发不高,晚上没人使用,第2天或者周一早上开始使用的人会登录特别缓慢。
分析
反复检查程序都没有发现问题,主要一开始怀疑IO的问题,因为内存中的一般不会出现超时的。但是没发现IO问题,却在无意间在上看到了一下提示。
2020-07-25 11:08:50 - [WARN ] [http-nio-8092-exec-10] o.a.c.util.SessionIdGeneratorBase : Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [28,190] milliseconds. 2020-07-25 11:08:50 - [WARN ] [http-nio-8092-exec-6] o.a.c.util.SessionIdGeneratorBase : Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [65,102] milliseconds. 2020-07-25 11:08:50 - [WARN ] [http-nio-8092-exec-2] o.a.c.util.SessionIdGeneratorBase : Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [166,254] milliseconds.
从日志可以看出,SessionIdGeneratorBase这个类要创建一个SecureRandom用于生成sessionID,居然用了几十秒到一百多秒不等的时间。
原因
原因是Tomcat在产生session ID时的SHA1PRANG算法使用了jre的SecureRandom。SHA1PRNG 算法是基于 SHA-1 算法实现且保密性较强的伪随机数生成器。而SHA1PRNG的种子产生器,是通过读取$JAVA_HOME/jre/lib/security/java.security 这个文件获取的,配置项为securerandom.source。
以下是java.security的配置片段:
# "file:/dev/urandom" will enable the native Microsoft CryptoAPI seeding # mechanism for SHA1PRNG. # # By default, an attempt is made to use the entropy gathering device # specified by the "securerandom.source" Security property. If an # exception occurs while accessing the specified URL: # # SHA1PRNG: # the traditional system/thread activity algorithm will be used. # # NativePRNG: # a default value of /dev/random will be used. If neither # are available, the implementation will be disabled. # "file" is the only currently supported protocol type. # # The entropy gathering device can also be specified with the System # property "java.security.egd". For example: # # % java -Djava.security.egd=file:/dev/random MainClass # # Specifying this System property will override the # "securerandom.source" Security property. # # In addition, if "file:/dev/random" or "file:/dev/urandom" is # specified, the "NativePRNG" implementation will be more preferred than # SHA1PRNG in the Sun provider. # securerandom.source=file:/dev/random
这个/dev/random被称为收集环境噪音的熵收集装置(也叫熵池The entropy gathering device),系统将当前运行的随机状态写入其中,作为伪随机数的种子。/dev/random非常适合那些需要非常高质量随机性的场景,比如一次性的支付或生成密钥的场景。但random有个特点就是阻塞式的,直到熵池收集到足够的环境噪声数据。由于长时间无人使用系统,就会导致熵池变空,从而无法产生随机数。我们看到这个配置的注释里也提到了另外一个文件,那就是/dev/urandom。它和/dev/random的区别就是,urandom是ublock的。
因此,由于无法产生随机数,jvm就阻塞住了,直至有足够的环境噪音,这样子随机数的随机行当然是高了很多,但也给系统带来了问题。可以将
securerandom.source=file:/dev/random
改为
securerandom.source=file:/dev/./urandom
为什么会多了个./呢,据说这是jvm的一个bug,有人反馈即使对 securerandom.source 设置为 /dev/urandom 它也仍然使用的 /dev/random。所以使用/dev/./urandom 这样的变通方法。也有人评论说这个不是 bug,是有意为之。