單點登錄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