突然寫了一篇關於CAS的文章，也是夠了，由於恰巧專案中在和移動端互動時出了一點問題，發現之前CAS的瞭解還是不夠清楚，再次重新記錄一下。

對於CAS的安裝什麼鬼玩意兒的，自己架構實現的，暫時不去管了，筆者專案中是spring-secret整合的。之前看過，但是沒有筆記，也不想記錄了，本篇就如標題，流程分析。

下圖為筆者重劃圖，CAS的時序圖看的不是很清晰，只能自己重新劃

還是結合專案的請求來說吧。

1. 首先請求 127.0.0.1:8080/xxxxx ，此時請求頭內並沒有Cookie資訊的存在，因此專案中生成了一個新的Cookie並返回給瀏覽器，臨時會話就此產生。

name : JsessionId  value: 12345678A。這個就是記錄在瀏覽器中和專案的會話Cookie，之後的請求都會帶著，那麼翻了一下程式碼，這個儲存在瀏覽器的Cookie有效期為30天，這個Cookie記錄的JsessionId記錄在專案中的redisSession中，設定的有效期為30分鐘。其實當第一次請求之後，如果授權成功的話，之後的請求都會帶著Cookie的JsessionId去訪問系統，系統發現這個JsessionId還沒有失效，說明當前為登入狀態，就不需要再去CAS拿這個使用者的登入資訊了。如果失效的話，這種情況下面再說。

2. 此時系統為當前使用者記錄了一個臨時會話，儲存的Id值就是Cookie的JsessionId，但是此時使用者還未登入，在響應頭中可以看見一個location 的URL，這個就是去登入CAS的。可以看見，login請求返回了一個登入頁面，此處由於未登入，如果此處是登入的情況，那麼返回時不一樣的，下面討論。響應頭內也返回了一個Cookie 的JsessionId，可以猜測和系統中使用的是一套東西。

3.翻看瀏覽器的記錄也能發現，當前維護的會話是哪些。一個是當前系統的會話，一個事CAS的會話。

4.下一步就是登陸了。看看登陸時操作了什麼，首先是POST請求CAS的login請求。可以看見這個login請求返回的是個302 URL。也就是下面的帶有票據 ticket的check請求。

那麼通過這種方式發給系統，帶有ticket。系統得到這個ticket之後，會在後臺傳送一個請求並帶上這個ticket去CAS驗證使用者使用這個合法的ticket，驗證有效後，返回使用者資訊。最終302 到一開始訪問的介面上，執行請求。此次login請求成功返回之後，其實在Cookie中記錄了一個叫CASTGC的東西。TGC存放了CAS服務端實現的叫做TGT的id，其實這個就是為之後系統判定使用者session失效後需要重定向到CAS去時帶的東西，如果找到，說明使用者之前登陸過，就不需要二次登入了。

5.到此，一次請求結束，那麼CAS和使用者就建立起了一個聯絡。CAS記錄了這個使用者的登入資訊。TGT，利用Cookie實現儲存了TGC，裡面記錄了TGT的id。

總結： 一次未授權登入過的請求執行時，最終會有兩個Cookie生成，一個是使用者與系統的，裡面記錄了JsessionId，這個會話在本系統的有效期為30分鐘，這個30分鐘是相對時間的概念。是一次請求和上次請求只要在間隔的30分鐘內，就不需要重定向到CAS去，而這個Cookie本身的有效期為30天，這是一個絕對時間的概念，在30天內，這個Cookie是有效的，但是裡面的的JSessionId的相對間隔時間只有30分鐘，這個是筆者公司的專案設計如此，不同的公司設計的是不一樣的。

接下來為二次請求同一系統，二次請求時會帶著JSessionId，

1.如果未失效的話，也就是系統判定為使用者為登入狀態，直接返回資源。

2.如果失效的話，會重定向到CAS去，請求如下。注意和第一次的區別，第一次請求時，請求頭內只有Cookie，並沒有TGC資訊。第二次請求時帶上了TGC資訊，這個資訊就是去找儲存在CAS的TGT資訊，如果TGT存在的話，直接請求location中的URL，這個URL帶上了ticket票據資訊。這邊和第一次登陸時差不多，但是和CAS的登入授權又有區別了，相當於這邊不在需要你登入了，直接給你跳轉到你的實際請求中去了。此處和CAS互動的JsessionId的過期時間暫時不知道，只知道這個Cookie本身的失效時間為30天。

接下去就是登入另一個系統了，暫且成為B。發現另一個系統的Cookie也生成。

請求CAS的時候還是獲取之前登入過的TGC資訊去CAS端獲取這個使用者的登入資訊，此處就是不知道當前Cookie中的CAS的tsid在公司CAS伺服器的Session設定的有效時間為多長，所以不好判斷，如果這個tsid也失效，會出現什麼情況。暫且忽略吧。此處請求發現了登入狀態，所以響應成功，跳轉到原始請求頁面。結束。

至此分析結束。只是基於請求狀態和流程圖分析了這個過程，無奈CAS服務端的實現並不能看見，所以無法進一步分析，CAS裡面的詳細處理過程，不過以上流程應該足夠你應付很多的場景了。先結帖，以後有幸的話再來更新吧。