根據 Next-auth 檔案，因為我們使用憑據提供程式連接到我們的用戶集合以獲取用戶名和密碼 Next-Auth 不使用會話資料庫來檢查會話是否處于活動狀態。
如果您使用自定義憑據提供程式，則 NextAuth.js 將不會將用戶帳戶保存在資料庫中（即使已配置）。必須啟用將 JSON Web 令牌用于會話令牌的選項（允許在不使用會話資料庫的情況下登錄）才能使用自定義憑據提供程式。
我想添加一個 _middleware，它允許我存盤并檢查會話資料庫中的最新 JWT 會話是否與用戶當前使用的最新會話匹配。
原因是，如果我在技術上擁有兩臺設備，我將能夠在兩臺設備上登錄，而目前他們無法辨別來自 PC2 的用戶是否也在 PC1 上登錄。
所以我的理論和不確定這是否可行是添加以下內容。
callbacks: {
jwt: async ({ token, user }) => {
console.log("running JWT - because of custom login")
user && (token.user = user)
(ADD CODE HERE TO SAVE TOKEN & CHECK IF TOKEN IS LATEST TOKEN VALID - INSIDE SESSION DATABASE)
(IF OLD-TOKEN IS NO LONGER VALID OR THE LATEST TOKEN LOG THE USER OUT)
console.log("TOKEN IS " JSON.stringify(token))
return token
},
session: async ({ session, token, user }) => {
console.log(JSON.stringify(session) " / " JSON.stringify(token) "/" JSON.stringify(user));
session.user.tokenID = token //ADD CODE HERE TO SAVE TOKEN TO SESSION COOKIE
session.user = user
return session
}
},
然后，如果我創建一個中間件來檢查此 tokenID 并將其與會話資料庫匹配，并且它是否是所述用戶的最新結果。
例如。
在這里說 PC1 (user1) 登錄
{
_id: 1
tokenID: 918171-918171-81716-0887
userid: 00-00-00-001
expire: "2022-05-23T12:47:04.593Z"
}
但隨后 PC2 也 (user1) 再次登錄并創建了一個新會話
{
_id: 2
tokenID: 71888-651777-616666-0117
userid: 00-00-00-001
expire: "2022-05-24T12:47:04.593Z"
}
我需要中間件做的（一個簡單的 mongodb 查詢可以做）是檢查它們是否是為相同用戶 ID 存盤的舊會話，如果是，則從 PC1 注銷。
現在有一些事情我可以看到這個想法出了問題。
- 其他提供者會話（使用會話資料庫）使其更難驗證
- 每次您呼叫注冊頁面或會話時，它似乎都會重新運行 JWT 部分——理論上這很好，因為我們可以使用 findOne 更新函式，如果令牌在會話中，則只需更新到期時間——但這會導致說PC1 在 PC2 登錄后重繪 ，然后 PC1 的過期時間可能比 PC2 的過期時間長（但是一個簡單的排序功能可以讓我們查看 ID 是否比 PC2 更早，如果是則注銷）。
- 每次重新加載頁面時 JWT 都會更改令牌
這將如何幫助隱私和用戶資料？
- 通過不在會話 cookie 中存盤用戶詳細資訊，我們不會將資料暴露給黑客或 FB 或 Google 等其他插件，因為用戶資料只會鏈接到令牌 ID。要請求用戶資料，您必須首先確保 tokenID 有效，然后才能獲取用戶資料。
我知道 Next-Auth 可能不想這樣做，這就是為什么我問這個問題，什么是做我想要實作的最佳實踐。
uj5u.com熱心網友回復：
此答案基于確認問題是您希望能夠讓用戶同時登錄到一臺計算機/設備，并且您正在使用用戶名和密碼對他們進行身份驗證。
在這種情況下，您還需要有一個資料庫來記錄每個 JWT 發出的令牌。沒有資料庫就不可能解決這個問題。
以下是使用 JWT 和資料庫解決它的方法：
- 每次新登錄時，您都需要使用
jwt回呼向每個 JWT 添加諸如 UUID 之類的內容，然后在資料庫中記錄該 UUID、用戶 ID 和 JWT 過期時間。 - 在該回呼中，如果資料庫中有相同用戶 ID 的其他條目，您應該將它們標記為無效（或從資料庫中洗掉它們）。
- 每次在同一個回呼中讀取現有 JWT 時，您都需要檢查資料庫中的 UUID 是否仍然有效（即仍然存在/不指向與標記為過期的 JWT 對應的 UUID）以及它是否不再有效，不要回傳有效的 JWT。
- 您可能還希望在
session回呼中添加特殊處理，通過在他們正在退出的計算機的用戶界面中優雅地處理它來執行類似的操作以改善用戶體驗。
實際上，這具有 JWT 的所有缺點以及會話資料庫的所有缺點（盡管在某些特殊情況下這是一種更可取的方法）。
我不建議使用用戶名和密碼或將用戶限制為一次只能登錄一臺計算機，但是考慮到那些例外具體的限制（這也需要對性能產生負面影響的解決方案），您可能需要考慮一個不同的身份驗證解決方案和/或考慮如何解決這個試圖解決的潛在需求（以及它是否值得成本和復雜性）。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/463098.html