將mongo ObjectId轉換爲字符串並將其用於URL可以嗎？

Question

document/show?id=4cf8ce8a8aad6957ff00005b 

Answer 1

一般來說，我認爲你應該謹慎，露出內部（如DB IDS）到客戶端。該URL可以很容易地被操縱，並且用戶有可能訪問你不希望他擁有的對象。

MongoDB的特殊，對象ID甚至可能會透露一些額外的內部結構（見here），即它們不是完全隨機的。這可能也是一個問題。

除此之外，我認爲沒有理由不使用的ID。

Answer 2

我普遍贊同@ MartinStettner的回覆。我想補充幾點，主要是闡述他所說的話。是的，少量的信息可以從ObjectId解碼。如果有人認識到這是一個MongoDB ObjectID，這是非常容易的。這兩個缺點是：

• 它可能允許某人猜測另一個有效的ObjectId，並請求該對象。
• 它可能會顯示有關該記錄的信息（例如其創建日期）或您不希望某人擁有的服務器。

「正確」的修復程序中的第一項是實現某種真實的訪問控制的：1）一個用戶具有與用戶名和密碼登錄，2）對象與用戶名相關聯，3）該應用程序僅向與該用戶名關聯的用戶提供對象。

MongoDB本身不會這樣做;你將不得不依靠其他手段。也許你的網絡應用程序框架，和/或一些臨時訪問控制列表（它本身可能在MongoDB中）。

但這裏是「速戰速決」這主要解決了兩個問題：創建其他一些「ID」備案的基礎上，一個大的，高品質的隨機數。

「大」需要多大？一個128位的隨機數有3.4 * 10^38的可能值。所以如果你的數據庫中有10,000,000個對象，那麼猜測一個有效值的人是一個極小的概率：3.4 * 10^31中的1。還不夠好？使用256位隨機數......或更高！

如何在文檔中表示這個數字？你可以使用一個字符串（將數字編碼爲十六進制或base64）或MongoDB的二進制類型。 （請查閱您的驅動程序的API文檔，瞭解如何創建二進制對象作爲文檔的一部分。）

儘管您可以向文檔添加新字段來保存此內容，那麼您可能還需要索引。所以文檔大小更大，並且您在該索引上花費更多的內存。以下是您可能沒有的內容：只需使用「真正的隨機ID」作爲您的文檔「_id」字段。因此，每個文檔的大小隻有一點點高，並且您使用的是您可能擁有的索引。