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