用 shortuuid 生成 userid、文章 id 来防止遍历，有比这个更好的方案吗？

[find456789]

数据库 mysql

目前数据库有个自增的数字 id， 但容易被遍历，

出于防止被对手看出动向 等原因

打算在前台输出 userid 和文章 id 的时候， 进行加密

目前打算 保留系统自带的 数字 id， 再额外增加一个 shortuuid 生成的字段，展现给前台用户

https://github.com/skorokithakis/shortuuid

大家觉得这个方案如何？

有没有更好的方案

比较追求性能、扩展性、安全性、性价比

[crysislinux]

可以只用 slug，禁止 id 直接访问。

[night98]

文章 id+uuid 的 sha1 值也可以，同时保存在数据库即可。

[MiffyLiye]

无序的 uuid 对数据库索引不友好，可以试试趋势有序的 snowflake
https://github.com/MiffyLiye/Snowflake

[find456789]

@crysislinux

请问 slug 是什么

[find456789]

@MiffyLiye

谢谢， 好像用 snowflake 需要额外一台服务器哦

[geelaw]

阻止遍历的最简单想法是这样做：使用自增的 id，并在 URL 上附加一个对该 id 的数字签名。

[MiffyLiye]

@find456789 可以分布式使用，我已经用上了其实。有其他问题，但是大部分问题在低频率创建（<4096 requests per 100 ms ）时不太会遇到。
https://bitbucket.org/MiffyLiye/miffy/src
以上 repo 公开 24 小时

[tscat]

可以做蜜罐吧。部分 id 不对外公开，一旦访问直接 ban ip。

[lyc9308]

对 id 做一下编码成本也很低啊

[ryd994]

@MiffyLiye 1. 随机字段索引影响不大，大的是随机主键
2. 就算是随机主键，新的数据库都已经有了相当的优化，或者提供了适合作为主键的随机函数

简单办法就是加上过期时间并签名。防顺序遍历够了。

[msg7086]

#4 @find456789


一般我觉得对 id 做编码就行了，映射到非连续空间，也不会影响性能。

[imzoke]

使用 hashids 吧
http://hashids.org

[honeycomb]

@find456789
snowflake，或者你按照它的原理写个变形。
如果是 hibernate/jpa，直接把它作为 generator 就可以。

不过 snowflake 这种 ID 生成方式会携带明确且准确的时间戳，不一定适用。