例如：http://stackoverflow.com/questions/396164/exposing-database-ids-security-risk并http://stackoverflow.com/questions/396164/blah-blah加载相同的问题。
（我猜这是 Questions 表的 DB id？这是 ASP.NET 中的标准吗？）
在您的 Web 应用程序中使用这种类型的方案有哪些优点和缺点？
sleepy
问问题
1086 次
5 回答
4
好吧，首先，简单的 id 通常是连续的，因此很容易猜测并从应用程序中检索其他数据。
在运行时加载 JSON，而不是通过 AJAX https://stackoverflow.com/questions/395858/doesnt-matter-what-I-type-here动态加载
现在，话虽如此，这也可能被视为一种奖励，因为没有人会认为他们的整个安全取决于您必须点击链接才能访问您的安全数据，因此很容易发现数据可能很好。
然而，有一点是你在某个时候要重新索引你的数据库，如果没有其他原因搜索引擎仍然有旧链接，那么让旧网址无效的东西会很糟糕。
此外，在 SO 上，将这样的链接用于其他问题是很正常的，所以如果他们在某个时候想要重新索引并因此重新编号（或移动到 guid），他们仍然必须保留旧的结构和 id。
现在，这可能会发生或需要吗？可能没有。
我不会太担心它，只需构建您的安全性，就好像您的应用程序的每个入口点都是已知的并且应该没有问题。
于 2009-01-02T15:36:18.023 回答
3
数据库 ID 用于在数据库中查找问题。它是数字，意思是：快。如果您将其省略，则必须查找要慢得多的标题。
问题本身是 url 的一部分，使其“搜索引擎友好”。它会被 g**gle 等排名更高。
于 2009-01-02T15:52:03.687 回答
1
临：
- 超级容易检索页面信息。拿ID，调用数据库，中提琴。您的表将（应该）被索引以使此查找超级快。
- 保证唯一的 URL。
缺点：
- 您系统中的 ID 正在公开显示。在像 SO 这样的公开系统中不是问题。但是，即使在敏感系统上，后端的适当安全措施也不会成为问题。
- 丑陋的网址。6 位以上的数字很难记住，并且如果数字是唯一可以识别它的页面，则更难以区分页面。这也可能产生 SEO 后果，因为具有更多相关和结构良好的信息的 URL 通常排名更好。SO 也通过在 URL 中提供帖子名称来进行补偿。虽然我仍然无法在午餐时向我的好友发出特定的帖子，但我仍然可以在浏览器历史记录中找到它更容易。
- 较慢的查找。在数据库上进行文本搜索通常较慢。
于 2009-01-02T16:06:01.007 回答
0
但请记住，在这样的社区中，同一问题名称同时发布的可能性更高（尽管仍然很小），这会破坏事情，因此需要应用某种唯一标识，ID 可能在开发此特定 Web 应用程序的上下文。
于 2009-01-02T15:40:07.517 回答
0
我不认为在 ASP.NET 和其他框架中这样做是不好的做法，而且相当普遍。正如@lassevk 所说，如果您的安全性取决于它，那么您需要在那里进行更多检查（用户 X 可以记录 Y），但这更多地归结为公共网站 URL 的 SEO 友好性。
例如，SO 的 URL相当友好：
谷歌在 URL 的开头对信息的评分高于结尾，所以看起来像：
https://stackoverflow.com/pros-and-cons-of-using-db-id-in-the-url/q/407120
应该在“在 url 中使用 db id 的利弊”获得更高的排名。这不是唯一的因素，但它是一个非常重要的因素 - 看看亚马逊的格式，他们这样做是有充分理由的：
Wordpress 是这样做的：
但是，如果您在同一天发布两个名为“foo”的帖子，您会得到：
slug (foo/foo2) 不是 PK，但它在帖子表中保持唯一。
我认为将 ID 放入 URL 中没有问题，除非您的 URL 是 GUID！太长了，很难打字。如果它是一个 int 或某种短 guid（例如 6-8 个字符），那么它应该不是问题。
于 2009-01-02T16:06:58.353 回答