在URL中公开数据库内部ID是不好的做法吗?
例如,假设我有一个users
表,每行有一些ID(主键)。公开网址myapp.com/accountInfo.html?userId=5
,其中5
是一个真正的主键,会被视为“坏事”,为什么会这样?
还假设我们正确防御SQL注入。
我最感兴趣的是与Java Web技术堆栈相关的答案(因此是java标签),但一般答案也会非常有用。
感谢。
答案 0 :(得分:7)
这取决于您解析URL的方式。如果允许盲目的SQL注入是不好的。您只需要从用户输入验证id。
如您在地址栏中看到的那样,Stackexchange还会将行的ID放入URL中。诀窍是解析部分并获得所有可能的SQL。简单的方法是检查id是否为数字。
答案 1 :(得分:7)
在URL中传递并不是一件坏事,因为它对最终用户没有太大意义 - 如果你在运行应用程序时依赖于该值,那么它就是唯一的错误。例如,您不希望用户注意到userId = 5并将其更改为userID = 10以显示另一个人的帐户。
将此信息存储在服务器上的会话中会更安全。例如,当用户登录时,其userID值存储在服务器上的会话中,并且每当查询数据库时都使用此值。如果你这样做,通常不需要传递URL中的userID,但是它不会受到影响,因为它不会被你的DB查询代码使用。
答案 2 :(得分:3)
是的,这是件坏事。您正在公开实现细节。多么糟糕?那要看。它会强制您对用户输入执行不必要的检查。如果其他应用程序依赖于它,则您不再可以自由更改数据库方案。
答案 3 :(得分:0)
在URL中使用数据库ID是好的,因为这个ID永远不会在对象(db rows)生命中发生变化。因此,URL是持久的 - 这是URL最重要的方面。另请参阅Cool URIs don't change。
答案 4 :(得分:0)
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会自动递增。