默認(rèn)情況下，Django 在數(shù)據(jù)庫里存儲會話（使用 ?django.contrib.sessions.models.Session? ）。雖然這很方便，但在一些設(shè)置里，在其他地方存儲會話數(shù)據(jù)速度更快，因此 Django 可以在文件系統(tǒng)或緩存中配置存儲會話數(shù)據(jù)。

使用數(shù)據(jù)庫支持的會話

如果你想使用數(shù)據(jù)庫支持的會話，你需要在 ?INSTALLED_APPS ?里添加 ?django.contrib.sessions?。
一旦在安裝中配置，運行 ?manage.py migrate? 來安裝單個數(shù)據(jù)庫表來存儲會話數(shù)據(jù)。

使用緩存會話

為了得到更好的性能，你可以使用基于緩存的會話后端。

使用 Django 的緩存系統(tǒng)來存儲會話，你首先需要確保已經(jīng)配置了緩存。

注意：如果您使用 Memcached 或 Redis 緩存后端，則應(yīng)僅使用基于緩存的會話。 本地內(nèi)存緩存后端保留數(shù)據(jù)的時間不足以成為一個好的選擇，并且直接使用文件或數(shù)據(jù)庫會話而不是通過文件或數(shù)據(jù)庫緩存后端發(fā)送所有內(nèi)容會更快。 此外，本地內(nèi)存緩存后端不是多進程安全的，因此可能不是生產(chǎn)環(huán)境的好選擇。

如果你在 ?CACHES ?定義了多緩存，Django 會使用默認(rèn)緩存。如果要使用其他緩存，請將 ?SESSION_CACHE_ALIAS ?設(shè)置為該緩存名。
一旦配置好了緩存，你有兩種辦法在緩存中存儲數(shù)據(jù)：

• 設(shè)置 ?SESSION_ENGINE ?為 ?django.contrib.sessions.backends.cache? 用于簡單緩存會話存儲。會話數(shù)據(jù)直接被存儲在緩存里。然而，會話數(shù)據(jù)可能不是長久的：因為緩存滿了或者緩存服務(wù)重啟了，所以緩存數(shù)據(jù)會被收回。
• 為了持久化緩存數(shù)據(jù)，設(shè)置 ?SESSION_ENGINE ?為 ?django.contrib.sessions.backends.cached_db ?。這使用直寫式緩存——每次寫入緩存的數(shù)據(jù)也會被寫入到數(shù)據(jù)庫。如果數(shù)據(jù)不在緩存中，會話僅使用數(shù)據(jù)庫進行讀取。

這兩中會話存儲會非常快，但簡單緩存會更快，因為它忽略了持久化。在大部分情況下，?cached_db ?后端將足夠快，但如果你需要最后一點的性能，并且愿意不時地刪除會話數(shù)據(jù)，那么 ?cache ?后端適合你。

使用基于文件的會話

要使用基于文件的會話，需要設(shè)置 ?SESSION_ENGINE ?為 ?django.contrib.sessions.backends.file?。

您可能還想設(shè)置 ?SESSION_FILE_PATH? （默認(rèn)為從 ?tempfile.gettempdir()? 輸出，很可能是 ?/tmp?）來控制 Django 存儲會話文件的位置。 請務(wù)必檢查您的 Web 服務(wù)器是否有權(quán)讀取和寫入此位置。

使用基于cookie的會話

要使用基于?cookies?的會話，需要設(shè)置 ?SESSION_ENGINE ?為 ?django.contrib.sessions.backends.signed_cookies?。這個會話數(shù)據(jù)將使用 Django 的加密工具 ?cryptographic signing?  和 ?SECRET_KEY ?工具進行保存。

建議將 ?SESSION_COOKIE_HTTPONLY ?設(shè)置為 ?True ?來防止通過 JavaScript 訪問存儲數(shù)據(jù)。

警告

如果 ?SECRET_KEY ?沒有保密并且您正在使用 ?PickleSerializer?，這可能會導(dǎo)致任意遠(yuǎn)程代碼執(zhí)行。

擁有 ?SECRET_KEY ?的攻擊者不僅可以生成您的站點信任的偽造會話數(shù)據(jù)，還可以遠(yuǎn)程執(zhí)行任意代碼，因為數(shù)據(jù)是使用 ?pickle ?序列化的。

如果您使用基于 ?cookie ?的會話，請?zhí)貏e注意您的密鑰始終完全保密，對于任何可以遠(yuǎn)程訪問的系統(tǒng)。

會話數(shù)據(jù)已簽名但未加密

使用 ?cookie后端時，客戶端可以讀取會話數(shù)據(jù)。

?MAC（Message Authentication Code）?用于保護數(shù)據(jù)不被客戶端更改，從而使會話數(shù)據(jù)在被篡改時失效。如果存儲 ?cookie ?的客戶端（例如您的用戶的瀏覽器）無法存儲所有會話 ?cookie ?并丟棄數(shù)據(jù)，則會發(fā)生同樣的失效。即使 Django 壓縮了數(shù)據(jù)，仍然完全有可能超過每個 ?cookie 4096? 字節(jié)的常見限制。

不保證新鮮

另請注意，雖然 ?MAC ?可以保證數(shù)據(jù)的真實性（它是由您的站點生成的，而不是其他人生成的）和數(shù)據(jù)的完整性（它都在那里并且正確），但它不能保證新鮮度，即您將被退回您發(fā)送給客戶的最后一件事。這意味著對于會話數(shù)據(jù)的某些用途，?cookie后端可能會使您面臨重放攻擊。與保留每個會話的服務(wù)器端記錄并在用戶注銷時使其失效的其他會話后端不同，基于 ?cookie的會話在用戶注銷時不會失效。因此，如果攻擊者竊取了用戶的 ?cookie?，即使用戶注銷，他們也可以使用該 ?cookie以該用戶身份登錄。只有在您的 ?SESSION_COOKIE_AGE之前，?Cookie ?才會被檢測為“陳舊”。

性能

最后，?cookie ?的大小會影響您網(wǎng)站的速度。