如何嚴格限制session在30分鐘後過時！

如何嚴格限制session在30分鐘後過時！
1.設置客戶端cookie的lifetime爲30分鐘；
2.設置session的最大存活週期也爲30分鐘；
3.爲每一個session值加入時間戳，而後在程序調用時進行判斷；

至於爲何，咱們首先來了解下php中session的基本原理：

PHP中的session有效期默認是1440秒（24分鐘），也就是說，客戶端超過24分鐘沒有刷新，當前session就會失效。固然若是用戶關閉了瀏覽器，會話也就結束了，Session天然也不存在了！
你們知道，Session儲存在服務器端，根據客戶端提供的SessionID來獲得這個用戶的文件，而後讀取文件，取得變量的值，SessionID可使用客戶端的Cookie或者Http1.1協議的
Query_String（就是訪問的URL的「?」後面的部分）來傳送給服務器，而後服務器讀取Session的目錄……
要控制Session的生命週期，首先咱們須要瞭解一下php.ini關於Session的相關設置（打開php.ini文件，在「[Session]」部分）：
一、session.use_cookies：默認的值是「1」，表明SessionID使用Cookie來傳遞，反之就是使用Query_String來傳遞；
二、session.name：這個就是SessionID儲存的變量名稱，多是Cookie，也多是Query_String來傳遞，默認值是「PHPSESSID」；
三、session.cookie_lifetime：這個表明SessionID在客戶端Cookie儲存的時間，默認是0，表明瀏覽器一關閉SessionID就做廢……就是由於這個因此Session不能永久使用！
四、session.gc_maxlifetime：這個是Session數據在服務器端儲存的時間，若是超過這個時間，那麼Session數據就自動刪除！
還有不少的設置，不過和本文相關的就是這些了，下面開始講如何設置Session的存活週期。
前面說過，服務器經過SessionID來讀取Session的數據，可是通常瀏覽器傳送的SessionID在瀏覽器關閉後就沒有了，那麼咱們只須要人爲的設置SessionID而且保存下來，不就能夠……
若是你擁有服務器的操做權限，那麼設置這個很是很是的簡單，只是須要進行以下的步驟：
一、把「session.use_cookies」設置爲1，使用Cookie來儲存SessionID，不過默認就是1，通常不用修改；
二、把「session.cookie_lifetime」改成你須要設置的時間（好比一個小時，就能夠設置爲3600，以秒爲單位）;
三、把「session.gc_maxlifetime」設置爲和「session.cookie_lifetime」同樣的時間；
在PHP的文檔中明確指出，設定session有效期的參數是session.gc_maxlifetime。能夠在php.ini文件中，或者經過ini_set()函數來修改這一參數。問題在於，通過屢次測試，修改這個
參數基本不起做用，session有效期仍然保持24分鐘的默認值。
因爲PHP的工做機制，它並無一個daemon線程，來定時地掃描session信息並判斷其是否失效。當一個有效請求發生時，PHP會根據全局變量
session.gc_probability/session.gc_divisor（一樣能夠經過php.ini或者ini_set()函數來修改）的值，來決定是否啓動一個GC（Garbage Collector）。
默認狀況下，session.gc_probability ＝ 1，session.gc_divisor ＝100，也就是說有1%的可能性會啓動GC。GC的工做，就是掃描全部的session信息，用當前時間減去session的最後修
改時間（modified date），同session.gc_maxlifetime參數進行比較，若是生存時間已經超過gc_maxlifetime，就把該session刪除。
到此爲止，工做一切正常。那爲何會發生gc_maxlifetime無效的狀況呢？
在默認狀況下，session信息會以文本文件的形式，被保存在系統的臨時文件目錄中。在Linux下，這一路徑一般爲\tmp，在 Windows下一般爲C:\Windows\Temp。當服務器上有多個PHP應
用時，它們會把本身的session文件都保存在同一個目錄中。一樣地，這些PHP應用也會按必定機率啓動GC，掃描全部的session文件。

問題在於，GC在工做時，並不會區分不一樣站點的session。舉例言之，站點A的gc_maxlifetime設置爲2小時，站點B的 gc_maxlifetime設置爲默認的24分鐘。當站點B的GC啓動時，它會掃
描公用的臨時文件目錄，把全部超過24分鐘的session文件所有刪除掉，而無論它們來自於站點A或B。這樣，站點A的gc_maxlifetime設置就形同虛設了。
找到問題所在，解決起來就很簡單了。修改session.save_path參數，或者使用session_save_path()函數，把保存session的目錄指向一個專用的目錄，gc_maxlifetime參數工做正常了。

還有一個問題就是，gc_maxlifetime只能保證session生存的最短期，並不可以保存在超過這一時間以後session信息當即會獲得刪除。由於GC是按機率啓動的，可能在某一個長時間內
都沒有被啓動，那麼大量的session在超過gc_maxlifetime之後仍然會有效。
解決這個問題的一個方法是，把session.gc_probability/session.gc_divisor的機率提升，若是提到100%，就會完全解決這個問題，但顯然會對性能形成嚴重的影響。另外一個方法是本身
在代碼中判斷當前session的生存時間，若是超出了 gc_maxlifetime，就清空當前session。