通常,在URL中总是散列唯一标识符是一个好主意?

通常在网站上 尝试 使他们容易爬行和获得所有的信息,以便你能得到良好的搜索排名和驱动流量到你的网站。优秀的Web开发人员在设计HTML时考虑到了搜索引擎,通常还提供RSS提要和站点地图等内容,以便更容易地对内容进行爬网。因此,如果你试图通过不使用顺序标识符使爬行变得更困难,那么(a)你不会使爬行变得更困难,因为爬行器是通过链接而不是通过猜测URL来工作的,(b)你试图使一些事情变得更困难,而你也会花时间使其变得更容易,这毫无意义。

如果你需要安全,那么使用 实际安全性 . 使用主体的检查来授权或拒绝访问资源。混淆URL根本不安全。

所以我看不出使用数字标识符有任何问题,也看不到试图混淆它们的任何值。

在ID上使用类似MD5或SHA的哈希不是一个好主意:

• 总有可能发生碰撞。也就是说,两个不同的ID散列到相同的值。
• 你要怎么把它解开回到实际的身份证上?

如果设置为避免增加ID,最好的方法是在创建ID时使用一个guid,或者只是一个随机值。

也就是说,如果您的应用程序安全性依赖于不猜测ID的人,那么系统中的其他地方就会出现一些缺陷。我的建议是:坚持使用简单的自动递增ID,并应用一些适当的访问控制。

我认为对公开可访问的ID进行散列不是一件坏事,但在某些情况下显示顺序ID的意愿是一件坏事。更好的是,对所有ID使用guid/uuids。您甚至可以在许多技术中使用顺序guid,因此速度更快(插入阶段)(尽管在分布式环境中没有那么好)

当您不希望URL可遍历时,散列或随机化标识符或其他URL组件是一个很好的实践。这是不安全的,但它会阻止爬虫使用(或滥用)您的服务器资源,并可以帮助您确定什么时候会发生这种情况。

通常,您不希望公开应用程序状态,例如将来将分配哪些ID,因为它可能允许攻击者以您不放弃的方式使用预测。例如,bind的顺序事务ID是 security flaw .

如果您确实希望鼓励爬行或其他遍历,那么更严格的方法是提供链接,而不是提供将来可能更改的实现细节。

使用连续整数作为ID可以使您的终端上的许多东西更便宜,并且可能是一个合理的折衷。

我的观点是,如果某个东西在网络上,并且在未经授权的情况下提供服务,那么它的目的是让公众可以访问它。积极尝试让访问变得更加困难似乎是违反直觉的。

通常,蜘蛛网是一件好事。如果你希望你的信息尽可能的可用,你希望像谷歌这样的网站在你的网站上收集数据,以便其他人可以找到它。

如果你不想让人们浏览你的网站,使用身份验证,并拒绝那些没有访问权限的人访问。

随机查找的URL只会给人安全的印象,而不会给人真实的印象。如果您将帐户信息(隐藏)在一个URL中,那么每个人都可以访问该Web蜘蛛的帐户。

我的一般规则是使用一个guid,如果我显示的东西必须在一个url中显示,并且还需要凭证来访问,或者对特定用户是唯一的(如订单ID)。 http://site.com/orders?id=e4da3b7fbbce2345d7772b0674a318d5

这样,另一个用户就不能通过黑客的网址“偷看”下一个订单。他们可能会被拒绝访问别人的订单,但向他们扔下数不清的字母和数字是一种非常明确的方式来表示“不要搞砸了”。

如果我显示的内容是公开的,而不是绑定到特定用户,那么我可以使用整数键。例如,为了显示图片,您可能希望允许您的用户黑客URL以查看下一张图片。

http://example.org/pictures?id=4 , http://example.org/pictures?id=5 等。

(实际上,我也不会将其作为一个简单的get参数,我会使用mod_rewrite(或其他方法)来创建可读的URL。类似的东西 http://example.org/pictures/4 -gt; /pictures.php?picture_id=4 等)

散列一个整数是一个模糊的安全性较差的实现,因此,如果这是目标,一个真正的guid,甚至一个“顺序”guid(无论是通过newsequentialid()还是通过comb算法)会更好。

不管怎样,没有人再输入URL了,所以我觉得担心长度的差异没有多大意义。