是否可以将 mongo ObjectId 转换为字符串并将其用于 URL？答案

【问题标题】：Is it ok to turn the mongo ObjectId into a string and use it for URLs?是否可以将 mongo ObjectId 转换为字符串并将其用于 URL？
【发布时间】：2010-12-03 12:26:23
【问题描述】：

document/show?id=4cf8ce8a8aad6957ff00005b

【问题讨论】：

标签： mongodb url database

【解决方案1】：

一般来说，我认为您应该谨慎地向客户端公开内部信息（例如数据库 ID）。该 URL 很容易被操纵，并且用户可能会访问您不希望他拥有的对象。

对于特殊的 MongoDB，对象 ID 甚至可能会揭示一些额外的内部结构（参见 here），即它们不是完全随机的。这也可能是个问题。

除此之外，我认为没有理由不使用 id。

【讨论】：

那么您会建议在客户端公开什么以便能够请求特定对象？你会在 BSON 对象中添加另一种类型的 id 吗？
他的意思是，如果您照常曝光，您可以更改字母并获得另一份您可能不应该这样做的文件。但是，我不同意这必然是一件坏事，因为那是默默无闻的安全，这根本不是安全。
ObjectID 可以告诉你它是什么时候创建的，什么机器，哪个进程，以什么顺序。因此，将其暴露给公众存在一些潜在的安全风险。一些讨论here.

【解决方案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”字段。因此，每个文档的大小仅略高一点，并且无论如何您都使用[可能]在那里拥有的索引。

【讨论】：

【解决方案3】：

我可以将 128 个字符的会话字符串和其他集合文档对象 ID 都设置为 cookie，并且当用户访问执行异步获取时，我会同时获取会话、用户和帐户。而不是先获取会话，然后再获取用户、帐户。如果会话文档有效，则共享用户和帐户文档。

如果我这样做，我将不得不对用户和帐户文档的每个请求都要求获取会话 128 字符会话 cookie，从而使暴露用户和帐户对象 ID 更安全。这意味着如果有人猜测用户 ID 或帐户 ID，他们还必须猜测 128 字符串才能从系统中获得任何答案。

您可以做的另一个安全措施是包装 id 是一些您只知道定位的盐，例如 XXX4cf8ce8XXXXa8aad6957fXXXXXXXf00005bXXXX 现在您确切地知道如何将其分割以获取 ID。

【讨论】：