Question

我有一个小小的困境，即如何在“猜测”他们的ID之前保护数据库中的数据，例如我们有一个地址：

http://example.com/users/34/edit

之后可以得出结论：35将是另一个用户，有人可能会尝试猜测该条目。那么如何保护自己免受类似的伤害呢？我正在考虑将PK替换为INT AI UUID（在应用程序端生成），但不会显着降低效率吗？
估计的条目数约为12,000，此后此ID将被链接，例如，个人资料你怎么看待这件事？

Answer 1

转到UUID。无论您如何生成主键，12,000条记录都不会对性能产生任何重大影响。作为奖励，如果您想要进行分片或任何类型的分布式系统，您很快就会发现UUID是维护此类系统的唯一方法。

Answer 2

其他选项（除了使用UUID作为密钥）：

除了（而非代替）ID之外，还要创建一个随机数或UUID 。将其作为同一表中的列存储在DB中。然后生成http://example.com/users/34/ {UUID或随机数} /编辑等网址。只有当UUID或随机数与数据库中的UUID或随机数匹配时，才允许编辑。

如果您不想存储额外的列，则可以加密ID并使用http://example.com/users/ {encryptedId} / edit等网址。在编辑期间，您将解密ID，并编辑解密的ID。除了ID之外，还可以使用加密的ID - 因此在允许编辑之前，您将验证解密的id与DB中的id相同，对应于id。

或者使用网址表中的其他列，例如http://example.com/users/34/ {LastName} /编辑并仅在姓氏与ID对应的数据库中的现有数据匹配时才允许编辑。

或者，如果您只是在服务器上进行会话或HTTP基本身份验证。几乎所有浏览器都支持基本身份验证（https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication#Basic_authentication_scheme） - 当您输入http://example.com/users/34/edit时，他们会提示您输入用户ID /密码。或者，您可以使用http://userid:password@example.com/users/34/edit
这样的网址

数据库 - 如何“保护”数据库以“猜测”记录

2 个答案: