背景 前段時間，項目計劃搞獨立的登錄鑒權中心，由於單獨開發一套穩定的登錄、鑒權代碼，工作量大，最終的方案是對開源鑒權中心CAS（Central Authentication Service）作適配修改。 實際應用中，web服務出於負載、容災的考慮，採用集群部署web服務（一般是tomcat集群），於
背景
前段時間，項目計劃搞獨立的登錄鑒權中心，由於單獨開發一套穩定的登錄、鑒權代碼，工作量大，最終的方案是對開源鑒權中心CAS（Central Authentication Service）作適配修改。
實際應用中，web服務出於負載、容災的考慮，採用集群部署web服務（一般是tomcat集群），於是有了CAS server端集群部署的需求。CAS集群部署，需要解決兩個問題：
- CAS票據共用，票據包括ST、TGT
- Tomcat session共用
需要作tomcat session共用，是由spring webflow框架引入的需求。CAS從3.x的版本開始，使用Spring Webflow框架，該框架需要在Tomcat session中存儲一些流程標識。預設配置下的tomcat，沒有做到session共用，因此需要使用一些技術手段，來完成tomcat的session共用。本文，即使用tomcat-redis-session-manager作tomcat session共用的一些總結。
運行環境：jdk_6，tomcat7
Session共用配置
採用第三方插件，tomcat-redis-session-manager來實現tomcat session共用。顧名思義，這種方案，是將tomcat session存儲到了redis（key value DB）中。
主要完成兩部分配置：
- jar包加到tomcat軟體的lib目錄下，如果運行環境不一致，可在此url（https://github.com/jcoleman/tomcat-redis-session-manager/downloads）中下載適合的tomcat-redis-session-manager包。
commons-pool-1.5.5.jar
jedis-2.1.0.jar
tomcat-redis-session-manager-1.1.jar
- 修改tomcat conf目錄下的context.xml配置文件，加上valve和manager配置段。其中maxInactiveInterval是session存儲時長，單位是秒。
<Valve className="com.radiadesign.catalina.session.RedisSessionHandlerValve" />
<Manager className="com.radiadesign.catalina.session.RedisSessionManager" host="ip" port="port" database="0" maxInactiveInterval="second"/>
完成這兩部配置，tomcat會把session放到redis中了。
Session不更新問題/解決
錶面現象
在cas login頁面，點擊【提交/登錄】按鈕，只是刷新該頁面，沒有真正的表單提交、驗證輸入的用戶名密碼的動作。
原因分析
--------------------------------------------------**CAS背景知識 **--------------------------------------------------
看過CAS服務端源碼的同學，會知道CAS登錄頁面會將下圖中的三個屬性，提交到CAS服務端的後臺：
其中_eventId和lt是CAS的業務邏輯使用的，
excetion是Spring webflow框架使用的，作用是根據excetion，來確定是否需要初始化一個新的cas login webflow實例，如果傳入的execution有效，進入之前的業務流。如果傳入的execution無效，則會初始新的webflow ，並生成一個新的execution。
--------------------------------------------------**CAS背景知識 **--------------------------------------------------
redis存儲tomcat session情況，CAS登錄頁面上元素【excetion】，多次刷新頁面不更新。Tomcat session預設策略下（不做特殊配置時，tomcat session預設在記憶體中），該元素的值，會隨頁面刷新變更。
而使用tomcat-redis-session-manager預設的session策略，會導致總是傳入無效的execution（筆者無效的execution為e2s1）。
查看源碼，webflow根據execution獲取會話，根據傳入的e2s1，獲取不到會話，進而重新生成execution。具體表現是重新刷新登錄頁面，不能走正常的“驗證表單”流程。
帶著問題繼續看源碼，execution無效，可能是webflow生成execution的時候出了問題。查看生成該屬性值代碼
context.assignFlowExecutionKey(); flowExecution.assignKey(); key = keyFactory.getKey(this);
經歷一系列內層調用，知道execution是根據session中key為webflowConversationContainer的屬性生成的，具體屬性包含以下內容：
execution的值和session屬性對象的欄位conversationIdSequence（int類型）相關，如果conversationIdSequence值為1，那execution的值即為e2--（conversationIdSequence自增1）。生成Execution的同時，正常情況session內容也相應變化，webflowConversationContainer屬性中新增了id為2的conversation，session寫入到redis中。
但是，按照tomcat-redis-session-manager預設的session策略，webflowConversationContainer屬性，key沒有變，value地址沒有變，認為session沒有更新，新的session內容沒有寫入到redis中。導致下次請求，取到的webflowConversationContainer屬性，沒有id為2的conversation，於是cas server端認定execution 為無效。導致刷新頁面，而非正常的流程：表單驗證。
確認session沒有寫入redis的步驟
l 增加一個filter，加入session.getAttribute("webflowConversationContainer")這樣的代碼，可以看到session中的屬性值，確實發生了變化；
l 根據JSESSIONID作為key，從redis中取到的session 串沒有變化。
解決辦法
l 按照《session同步時自定義類對象屬性保存不上的解決方法》所述，修改tomcat-redis-session-manager 臟數據判定策略。
l 或者在增加一個filter，攔截login請求，新增一個key為”xxx_flag”，value為System.currentTimeMillis()的屬性，這樣，tomcat-redis-session-manager認定你的session數據是變化了的，會將新的session數據，寫入到redis中，進而保證後續使用正常。
