保护纯客户端骨干应用程序

Protecting Purely Client-Side Backbone Applications

本文关键字:应用程序 客户端 保护      更新时间:2023-09-26

假设我要执行一款拼字游戏,我希望它100%是客户端,即主干处理所有游戏逻辑。是否有可能保护这样的解决方案,使用户无法欺骗游戏移动?

这可能吗?

我认为有几件事必须留在服务器端,即使在(几乎)全客户端解决方案

  1. Security—您必须在客户端之外进行某种授权和身份验证
  2. 验证 -你永远不能相信用户生成的内容,在骨干同步期间发送到服务器的JSON模型,在某种程度上是用户生成的内容(因为任何人都可以打开控制台并打乱你的模型并保存)

我知道像Firebase这样的解决方案可以很好地处理#1,但我不确定它们是否可以处理#2

因此,在这种情况下,ssamubastien的答案是一个很好的解决方案,而不是服务器验证,您让对等体根据他们对游戏的表示来验证他们从其他对等体获得的是一个有效的移动。然而,你怎么知道谁是对的呢?多数人赢了?我看不出有什么方法可以避免出现某种服务器端状态,即"主"状态并验证每个移动都是"有效"移动。

一种方法是让你的服务器端运行在Node.js上,这样你就可以避免在两个不同的地方重写你的验证逻辑。您不需要在服务器端运行整个逻辑,只需运行验证部分。

也有一些方法可以在服务器端运行整个Backbone应用程序(例如这种方法),但我不确定这里是否需要。

需要服务器端验证的其他几个原因:你如何知道用户在保存什么?例如,如果你没有设置大小限制,是什么阻止他们将整个盗版电子书数据库存储在你的应用中,如果你在服务器端没有验证,任何拥有主机的人理论上都可以推送任何内容。

这是不可能的,除非您还构建了一种方式,让一个客户端告诉另一个客户端停止作弊,或者换句话说,本地验证每一次移动。然而,这有一个相反的问题,即允许作弊者阻止对手的每一个动作。

你可以通过让第三人与客户"间接观察"游戏,并提供有关移动的第三方观点来扩展这一点。如果三分之二的人认为一项行动是合法的,那么这项行动就会通过。只有当你有大量的作弊者或修改脚本的人时,这才会崩溃。

我认为这将是你唯一的解决方案之一,因为,如果应用程序完全是客户端,你可以认为代码中没有任何东西是安全的或牢不可破的。我认为,您需要更多地依赖于对等验证,而不是在代码中构建检查。