我正在構建一個java + angularjs應用程序。我在客戶端實現了會話超時,如果用戶沒有任何活動30分鐘,則會向服務器發送請求以使會話令牌過期。是否應該實現服務器端超時?
如果服務器端的超時也是單獨存在的,即如果服務器的連接沒有關閉,例如5小時或一天,則自動使服務器端的會話令牌失效,並通過發送401 ?
另一個想到的情況是,如果我與其他應用程序分開使用API,我的API是否永遠不會超時?或者應該有一個會話持續時間,因爲我在服務器端管理會話令牌。
我正在構建一個java + angularjs應用程序。我在客戶端實現了會話超時,如果用戶沒有任何活動30分鐘,則會向服務器發送請求以使會話令牌過期。是否應該實現服務器端超時?
如果服務器端的超時也是單獨存在的,即如果服務器的連接沒有關閉,例如5小時或一天,則自動使服務器端的會話令牌失效,並通過發送401 ?
另一個想到的情況是,如果我與其他應用程序分開使用API,我的API是否永遠不會超時?或者應該有一個會話持續時間,因爲我在服務器端管理會話令牌。
恕我直言,保持會話令牌在你的服務器上的一個TTL
(生存時間,基本上你的令牌將從數據存儲中刪除,如果沒有任何活動一段時間)將是最好的辦法。許多數據存儲具有實現此功能的機制,並在TTL
過期時自動刪除會話令牌;對於這種情況,我建議Redis
。保持服務器端的會話安全性是必需的。
如果您正在向不同的應用程序提供API,那麼使用相同的機制是有意義的。只要用戶登錄到系統並已通過系統授予其他應用程序的權限,您就可以登錄到其他應用程序。
Redis有TTL,但沒有滑動過期,所以您必須在服務器端或Redis上使用lua腳本實現它 –
服務器端是負責會話超時的人。否則,惡意(或損壞)客戶端可能會導致服務器出現問題(例如,在服務器上創建100000個會話並且不會對它們進行計時)。 – Kayaman
當然。服務器端超時應該比客戶端超時更積極。服務器是消耗多個每會話資源的服務器。客戶端只有一個會話。 – EJP