我的應用程序是一個完整的AJAX網頁使用Codeigniter框架和memcached會話處理程序。會話重新生成導致快速AJAX調用過期的會話
有時，它會發送很多異步調用，並且如果會話必須重新生成其ID（以避免會話固定安全問題），會話Cookie不會更新得足夠快，並且由於會話ID過期，某些AJAX調用會失敗。
這裏是一個示意圖圖片我做出清晰顯示問題： 
我遇到類似的走線（例如this one），但答案並不能真正解決我的問題，我不能禁用因爲在我的應用程序中只有AJAX調用的安全性。不過，我有一個想法，我希望在入侵Codeigniter會話處理程序類之前提出一個意見： 這個想法是管理2個同時會話ID一段時間，例如30秒。這將是最大的請求執行時間。因此，在會話重新生成後，服務器仍然會接受以前的會話ID，並切換到新的會話。 使用，這將使這樣的事情同樣的畫面：
您的問題似乎與要求的實際速度要少（雖然它是一個促進因素），但更多的併發。 如果我理解正確，您的JavaScript應用程序會進行許多（異步）ajax調用 - 快速（大概是以突發形式） - 並且有時由於您認爲請求問題的速度會導致會話失效，有時會失敗。 嗯，我認爲問題是，你實際上有幾個併發請求到服務器，而第一個有其會議更新另一個本質上不能看到它，因爲請求已經完成，並等待由服務器處理。
這個問題當然會體現出來，只有當同時爲同一個用戶做幾個請求時纔會出現。
現在真正的問題在這裏 - 您的應用程序業務邏輯需要什麼？
在我看來，你正試圖找到一個'業務'問題的技術解決方案。我的意思是說，要麼你錯誤地解釋了你的要求，要麼那些要求不是那麼好的想法/規定。
我會建議你嘗試以下一些：
問自己，如果這些多個同時請求可以組合到一個
深人地觀察的要求，並試圖找到真正的理由你爲什麼要做你可能做的事情，也許這裏沒有真正的商業原因
每次你發起一系列的請求之前，每次發起一個'刷新'ajax請求來獲得新的會話，並且只在su連接所有其他請求
希望我寫了一些幫助指導您解決方案。 好運
鑑於具有類似問題的人數多，我不認爲「改變您的業務邏輯」最終將成爲答案。我同意可能會有一些業務邏輯改進，但這裏似乎也有一個真正的CodeIgniter技術問題。在FE上使用諾言鏈也可能會有所幫助，並會觸及雙方（技術和邏輯），但同樣不會完全解決問題。 – ldg
您好，我正在嘗試引導您對問題進行嘗試和思考。但我確實提出了兩種技術方法來緩解它。當然，這個實現是由你自己決定的。無論如何，我仍然直覺地認爲，爲同一用戶觸發許多併發的Ajax調用是一件奇怪的事情，可以，也應該避免。所以是的，我仍然會說你可能解決了錯誤的問題。也許你可以在這裏描述用例來給出上下文，然後也許我會看到我錯了，並可以幫助你更好？ –
@ VladLyga第一：感謝您的回答。正如Idg所說，這個問題可能發生在不同的商業案例中。我描述了一個突發的用例，我可以將它轉換爲分組請求（對於網絡吞吐量，性能和可靠性也會更好）。但是，這個問題可能發生在一個更簡單（並且不可更改）的用例中：假設我有一個每分鐘運行一次的刷新計數器，如果在會話重新生成時同時運行另一個異步請求，則第一個請求重新生成會話，第二次被踢，並拋出驗證彈出窗口。 –
首先，你提出的解決方案是比較合理的。實際上，the people at OSWAP只是建議：
Web應用程序可以實現額外的更新超時，在此之後會話ID自動更新。 （......）以前的會話ID值依然將是有效的一段時間， 容納安全間隔，以前的客戶瞭解新 ID，並使用它開始。那時，當客戶端在當前會話內切換到 新ID時，應用程序使 先前ID失效。
不幸的是，這不能用PHP的標準會話管理來實現（或者我不知道該怎麼做）。儘管如此，在a custom session driver 中實施此行爲不應該造成任何嚴重問題。
現在我要提出一個大膽的聲明：定期再生會話ID的整體思路，是壞了。現在不要誤會我的意思，在登錄再生會話ID（或者更準確地說，as OSWAP put it，在「權限級別的變化」）確實是針對session fixation一個非常出色的防守。
但再生會話ID 定期帶來更多的問題比它解決的：在間隔期間，當兩會並存，它們必須同步，否則一個運行風險失去從到期的會話信息。
有反對簡單的會話盜竊更好（更容易）防禦：使用SSL（HTTPS）。定期會話更新應視爲對此攻擊向量的the poor man's workaround。
我真的很喜歡你的答案，因爲你搜索了OWASP語句，這是我真正依賴的安全參考。但是，HTTPS是不夠的，許多公司都違反了他們的SSL解密/加密，使得內部黑客入侵白盒子。 強大的安全性是一個有很多障礙的安全性。 目前，我將依靠memcached會話垃圾回收器並使用「不要破壞會話更新」功能。這不是最佳的，但它仍然會比沒有任何事情更好。 –
我不太清楚你所抵禦的威脅模式。如果您擔心利用SSL實施方式進行攻擊，則優先考慮進行修復，因爲如果這種攻擊受到威脅，則其他任何防禦措施都變得毫無意義。如果你擔心內部工作，那麼我認爲定期會議再生將毫無幫助。 – RandomSeed
很多大公司都有防火牆阻止某種流量，例如以VOIP爲例。爲此，他們有一個應用程序創建SSL握手的前端代理，SSL連接不會完全通向用戶。 （我是這個應用程序，我無法處理所有的用戶基礎設施，我是一個雲服務軟件） 之後，此代理讀取網絡數據包並完成他的工作，檢測其所有規則。然後，與員工用戶使用內部證書開始新的握手：此證書可能已損壞。 –
您正在使用什麼版本的CI的？這似乎是CI會話處理中的一個持續性錯誤，特別是對於db會話。我認爲支持多個會話ID可能會像黑客一樣工作，但似乎是在尋求麻煩。你可以使用其他的會話處理程序，也許使用Redis或類似的本地PHP會話嗎？你也看過[這個主題]（https://github.com/bcit-ci/CodeIgniter/issues/3097）嗎？ – ldg
@Idg：我讀了所有這些線程。它講述了這個問題，CI3（我的版本）通過禁用AJAX請求更新會話來解決這個問題。問題是我唯一的* *在我的應用程序的AJAX請求.... –
@NicolasThery你能簡單的介紹一下什麼樣的，你有 –