在URL中公开DB内部ID是不好的做法吗？

Question

在URL中公开数据库内部ID是不好的做法吗？

例如，假设我有一个users表，每行有一些ID（主键）。公开网址myapp.com/accountInfo.html?userId=5，其中5是一个真正的主键，会被视为“坏事”，为什么会这样？

还假设我们正确防御SQL注入。

我最感兴趣的是与Java Web技术堆栈相关的答案（因此是java标签），但一般答案也会非常有用。

感谢。

Answer 1

这取决于您解析URL的方式。如果允许盲目的SQL注入是不好的。您只需要从用户输入验证id。

如您在地址栏中看到的那样，Stackexchange还会将行的ID放入URL中。诀窍是解析部分并获得所有可能的SQL。简单的方法是检查id是否为数字。

Answer 2

在URL中传递并不是一件坏事，因为它对最终用户没有太大意义 - 如果你在运行应用程序时依赖于该值，那么它就是唯一的错误。例如，您不希望用户注意到userId = 5并将其更改为userID = 10以显示另一个人的帐户。

将此信息存储在服务器上的会话中会更安全。例如，当用户登录时，其userID值存储在服务器上的会话中，并且每当查询数据库时都使用此值。如果你这样做，通常不需要传递URL中的userID，但是它不会受到影响，因为它不会被你的DB查询代码使用。

Answer 3

是的，这是件坏事。您正在公开实现细节。多么糟糕？那要看。它会强制您对用户输入执行不必要的检查。如果其他应用程序依赖于它，则您不再可以自由更改数据库方案。

Answer 4

在URL中使用数据库ID是好的，因为这个ID永远不会在对象（db rows）生命中发生变化。因此，URL是持久的 - 这是URL最重要的方面。另请参阅Cool URIs don't change。

Answer 5

PKs适用于该系统 对于用户来说，它可能代表不同的含义：
对于例如 让我们考虑以下链接。使用主键，它显示产品
productA，productB，productC下的项目;

（A） http://blahblahsite.com/browse/productA/111（pkey）
  （B） http://blahblahsite.com/browse/productB/112（pkey）
  （C） http://blahblahsite.com/browse/productC/113（pkey）
链接 B 上的用户可能会觉得ProductB下有112个项目，这会产生误导。

同时它会在合并表时引起问题，因为PK会自动递增。