Django4.0 使用會(huì)話-配置會(huì)話(session)引擎

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

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

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

使用緩存會(huì)話

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

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

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

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

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

這兩中會(huì)話存儲(chǔ)會(huì)非?？?，但簡(jiǎn)單緩存會(huì)更快，因?yàn)樗雎粤顺志没?。在大部分情況下，?cached_db ?后端將足夠快，但如果你需要最后一點(diǎn)的性能，并且愿意不時(shí)地刪除會(huì)話數(shù)據(jù)，那么 ?cache ?后端適合你。

使用基于文件的會(huì)話

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

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

使用基于cookie的會(huì)話

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

建議將 ?SESSION_COOKIE_HTTPONLY ?設(shè)置為 ?True ?來(lái)防止通過(guò) JavaScript 訪問(wèn)存儲(chǔ)數(shù)據(jù)。

警告

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

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

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

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

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

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

不保證新鮮

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

性能

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