在 URL 中使用 DB id 的优缺点？答案

【问题标题】：Pros and cons of using DB id in the URL?在 URL 中使用 DB id 的优缺点？
【发布时间】：2010-09-29 06:12:00
【问题描述】：

例如：http://stackoverflow.com/questions/396164/exposing-database-ids-security-risk 和 http://stackoverflow.com/questions/396164/blah-blah 加载相同的问题。

（我猜这是 Questions 表的 DB id？这是 ASP.NET 中的标准吗？）

在您的网络应用中使用这种类型的方案有什么优缺点？

【问题讨论】：

【解决方案1】：

首先，简单的 id 通常是连续的，因此很容易猜测并从您的应用程序中检索其他数据。

现在，话虽如此，这也可能被视为一种奖励，因为没有人会认为他们的整个安全取决于您必须点击链接才能访问您的安全数据，因此数据的容易发现性可能很好。

但是，有一点是您在某个时候要重新索引您的数据库，如果没有其他原因搜索引擎仍然具有旧链接，那么拥有使旧网址无效的东西会很糟糕。

此外，在 SO 上，将这样的链接用于其他问题是很正常的，所以如果他们在某个时候想要重新索引并因此重新编号（或移动到 guid），他们仍然必须保持旧结构和身份证。

现在，这可能会发生或需要吗？可能没有。

我不会太担心它，只需构建您的安全性，就好像您的应用程序的每个入口点都是已知的并且应该没有问题。

【讨论】：

【解决方案2】：

【讨论】：

【解决方案3】：

专业版：

缺点：

您系统中的 ID 正在公开显示。在像 SO 这样的公开系统中不是问题。但是，即使在敏感系统上，适当的后端安全措施也不会成为问题。
难看的 URL。 6 位以上的数字很难记住，并且如果数字是唯一可以识别它的页面，则更难以区分页面。这也可能产生 SEO 后果，因为具有更多相关和结构良好的信息的 URL 通常排名更好。 SO 也通过在 URL 中提供帖子名称来进行补偿。虽然我仍然不能在午餐时向我的好友喋喋不休地发一条特定的帖子，但我仍然可以在浏览器历史记录中找到它更容易。
查找速度较慢。在数据库上进行文本搜索通常比较慢。

【讨论】：

【解决方案4】：

但请记住，在这样的社区中，同一问题名称同时发布的可能性更高（尽管仍然很小），这会破坏事情，因此需要应用某种唯一标识，ID 可能是在开发此特定 Web 应用程序的上下文中非常合乎逻辑。

【讨论】：

【解决方案5】：

我不认为在 ASP.NET 和其他框架中这样做是不好的做法，而且相当普遍。正如@lassevk 所说，如果您的安全性取决于它，那么您需要在那里进行更多检查（用户 X 可以记录 Y），但这更多地归结为公共网站 URL 的 SEO 友好性。

例如，SO 的网址相当友好：

Pros and cons of using DB id in the URL?

google 对 URL 开头的信息的评分高于结尾，因此看起来像：

https://stackoverflow.com/pros-and-cons-of-using-db-id-in-the-url/q/407120

应该在“在url中使用db id的利弊”获得更高的排名。这不是唯一的因素，但它是一个非常重要的因素 - 看看亚马逊的格式，他们这样做是有充分理由的：

http://www.amazon.com/Maverick-Ricardo-Semler/dp/0712678867

http://server/book-name/dp/book-id

Wordpress 是这样做的：

http://server/yyyy/mm/dd/name-of-the-post

但是，如果您在同一天发布两个名为“foo”的帖子，您会得到：

http://server/yyyy/mm/dd/foo

http://server/yyyy/mm/dd/foo2

slug (foo/foo2) 不是 PK，但它在帖子表中保持唯一。

我认为将 ID 放入 URL 中没有问题，除非您的 URL 是 GUID！太长了，很难打字。如果它是一个 int 或某种短 guid（例如 6-8 个字符），那么它应该不是问题。

【讨论】：