2011-04-12 53 views

回答

2

對於幾乎所有情況,餅乾都是最好的。它們很簡單,因爲它們只依賴於服務器進程正在響應以及用戶的瀏覽器像瀏覽器一樣工作的事實。

Cookie不適合存儲大量的數據或數據,這些數據或數據應該從用戶隱藏,但這意味着您不應該將這些內容放在會話中。這通常不是問題,只要你牢記這個限制。

+0

Cookie的問題是高級用戶更改值的能力。還有每個請求來回發送數據,這似乎是過度殺傷。寧願發送一個鍵來查找數據。 – chrishomer 2011-04-12 05:00:23

+2

@ChrisH - 「爲了防止會話哈希被篡改,摘要會根據會話與服務器端祕密進行計算並插入cookie的末尾。」 http://guides.rubyonrails.org/security.html。由於會話數據應該保持較小,所以來回發送不成問題。此外,cookie只在服務器發生更改時纔會發送。 – 2011-04-12 05:12:17

3

安全性應該是一個問題。請記住,可以使用瀏覽器代理修改存儲在客戶端的任何內容(如cookie,表單POST參數,GET參數等)。因此,始終驗證通過瀏覽器返回的任何內容。您可以加密cookie中的值或形成POST參數。另外,正如史蒂夫所說,Cookie通常只應用於小數值。

如果你不打算在服務器集羣上運行,或者如果你是,如果你可以忍受用戶的會話在服務器關閉時丟失的話,那麼默認的基於文件的方法是非常好的重新登錄)。對於絕大多數應用程序,這是完全可以接受的。您需要將負載均衡器配置爲「粘性會話」,這意味着給定用戶綁定到單個服務器。但是,這可能會使負載平衡變得更加困難,因爲您有時會發現許多用戶都綁定到一臺服務器,而另一臺服務器卻處於空閒狀態。

如果您需要跨集羣共享會話狀態,那麼您有幾個主要選項。如果你的流量不是極端的,你可以處理一點額外的延遲,那麼你可以將會話信息存儲在數據庫中。只要數據庫啓動,會話數據就不會丟失。如果數據庫關閉,那麼會話數據可能是您最擔心的問題。如果您的應用具有非常高的流量,或者令人難以置信的性能至關重要,那麼您最好的辦法就是使用分佈式緩存,例如memcached。然而,這是額外的「基礎設施」,你將不得不維護和監視。即使memcached已經發布,它仍然是您添加到應用程序環境的額外失敗點。所以,如果你不需要它,不要輕視它。爲了長話短說,我假設基於默認文件的會話存儲方法對於90%以上的應用程序來說可能是完全可以接受的。

+1

我們已經在使用db store,並且擔心增加的延遲 - 似乎要求100ms左右的請求...... memcache可能會失敗,但我不想強制登錄。由於Redis可以定期寫入光盤,因此redis看起來稍微好一點 - 但是我沒有使用redis的經驗,也不確定它是否將緩存和會話存儲中的memcache替換爲它。 「原來的問題比原來的問題更廣泛,但它存在於...」 – chrishomer 2011-04-12 04:56:19

+0

「爲了防止會話哈希被篡改,摘要會從具有服務器端祕密的會話中計算出來並插入cookie的末尾。 guides.rubyonrails.org/security.html。 – 2011-04-12 05:13:34

+0

100ms看起來過多。你有沒有在數據庫中調整會話存儲?會話信息的讀/寫比率是多少?您可以在每次寫入時持久化數據庫,但在memcached中緩存,如果存在,則不查詢數據庫,而只是直接從緩存中查詢。如果會話在緩存中不存在(因爲可能服務器已經死掉),請查詢數據庫以填充緩存。只要服務器保持活動狀態,就可以使用粘性會話,因此通常會話信息位於特定服務器上。 – squawknull 2011-04-13 01:04:59

相關問題