将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”字段。因此，每个文档的大小只有一点点高，并且您使用的是您可能拥有的索引。