虽然我总是检查某人是否被允许访问记录，但我通常在查询字符串中使用UID，因为我觉得它不鼓励“捅”那个诱惑？id = 1，？id = 2呢。
我发现，由于您需要存储UID而不仅仅是记录ID，因此在多个表中进行查找会让人感到有点费解。
如果我要通过查询字符串传递一个id号的加密字符串然后解密它来进行数据库查询会增加大量开销吗？
这意味着我可以使用主键（虽然我仍然会检查他们是否有权查看记录）并且可以在每个会话中创建唯一链接（或在整个会话中随时更改） - 这将是有用的如果有很多AJAX驱动的内容，你不希望他们试图玩。
这是一个非常糟糕的主意吗？
答案 0 :(得分：0)
为什么不只是base64encode /解码ID？如果你只是这样做是为了防止合法用户尝试玩具，事实上他们确实有权玩游戏，那么做任何特别想要阻止它们的事情都没有任何意义。
答案 1 :(得分：0)
您绝对应该检查每个请求的权限。您永远不应该只依赖输入数据来保证安全！
请记住，如果您可以解密它，那么想要攻击您网站的恶意用户也是如此。
使用会话来存储权限是一种有利于性能的折衷安全性，我认为这样做的平均安全性。
但仍然 - 如果你有敏感数据 - 每次检查每个请求。不要以安全性较低的名义优化几微秒。
现在我在评论中看到了你的真正问题，我可以建议为用户进行的每次刷新使用某种额外的哈希，并将其保存在用户的会话中。然后检查用户是否使用相同的散列，例如：
$hash = md5(microtime());
$_SESSION['secret_user_hash'] = $hash;
并将其放在URL中，如：
&z=<?php echo substr($hash, 5, 10); ?>
用户发出请求后，只检查它是否是相同的哈希值。
请记住，如果您使用的是重型AJAX，则应在会话中更改哈希时更新哈希值。我能想到的最好的方法是在随机hashesh（例如5）的会话中保持一个数组，并随机使用它们进行查询。所以你有一个更大的游泳池，你不必在每次请求后更新。
答案 2 :(得分：0)
让您的UID成为哈希并传递它。
除非您不想重构整个架构和代码库，否则rot13 / base64会对其进行编码。
答案 3 :(得分：-1)
为什么它会影响您访问数据的方式，访问和显示是两个独立的实体。 您的密钥应该在查询中使用，但如果您不想，则永远不需要显示它。你可以哈希它，你可以修改重写，所以它永远不会在网址中可见...有很多选项，同时仍然查询你的表中的键。如果你设置了一个模式，你甚至可以动态生成它。 P + IDHASH + ANATTRIBUTE等等。在整数上使用base64并解码来运行查询不会花费你超过毫秒左右的时间。请记住，您的查询中没有散列，因此它们将保持不变，您将编码/解码一个不是时间问题的项目