保护客户端 API [英] Securing a client-side API
问题描述
我正在为基于 JavaScript 的游戏构建服务器端 API 和客户端库，其中两个非常重要的功能必须得到保护.
I'm building a server-side API and client-side library for a JavaScript-based game where two very important features must be secured.
- 每次播放都必须向用户收取费用
- 我们必须确保提交的分数是玩家实际获得的分数.
解决第一个问题似乎很简单；在每次播放开始时，我们点击 API，从用户的帐户中扣款并返回一个唯一的播放 ID.当我们提交用户对那场比赛的评分时，我们传递了开始时发出的 ID.
Solving the first problem seems simple; at the beginning of each play we hit the API, debit the user's account and return a unique Play ID. When we submit the user's score for that play, we pass the ID issued at the beginning.
第二个让我有点难倒.最初，我考虑了基于 ID 和分数的客户端散列算法，但很快意识到生成散列的 Javascript 很容易被逆向工程，即使它被混淆了.此时我考虑了一个生成hash的小flash组件，但我听说即使编译的flash也可以反编译.
The second one has me a little stumped. Initially I considered a client-side hashing algorithm based on the ID and the score, but quickly realized that the Javascript that produces the hash could easily be reverse-engineered, even if it was obfuscated. At this point I considered a small flash component that generates the hash, but I've heard that even compiled flash can be decompiled.
为了增加上下文，我计划用 Ruby 构建服务器端 API.
For added context, I plan to build the server side API in Ruby.
我很想听听 Stack Overflow 的聪明程序员提供的任何建议.感谢您的时间！
I'd love to hear any suggestions the clever programmers of Stack Overflow have to offer. Thanks for your time!
下面 Homer6 的回答对于更复杂的游戏来说是一个很好的解决方案，但不幸的是，这款游戏的简单性并不值得采用这样的方法.这是一款非常短的游戏时间，所以分数就是你完成一个关卡所需的时间.
The answer by Homer6 below is a very good solution for more sophisticated games, but unfortunately the simplicity of this game doesn't merit a method like that. It's a very short-play time based game, so the score is just the time it takes you to complete a level.
推荐答案
根据经验，只需假设客户端中的任何内容都可以伪造.
As a rule of thumb just assume that anything in the client side can be faked.
这篇关于保护客户端 API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
