做一个微信小游戏，游戏结果积分抽奖。但是不想被用户不玩直接提交结果。js代码又是开源的，要怎么处理。
之前做过类似的手游。当时处理的思路是这样的。
整个网站是https的，自带检测手机UA和触摸屏（尽可能防止PC模拟），页面里面的js混淆，跟服务器互动都用可逆的加密算法。
开始游戏之前向服务器申请加入游戏。服务器返回唯一的token作为本局游戏的ID。
因为我们的那个小游戏有涉及一些触摸的行为，在游戏过程中会将行为存好，结束游戏后将token、分数还有行为数据传上服务器。
至于怎么判断有没有作弊，无非就是检查时间差还有行为能否得到最后结果。
最后结果返回。
不过游戏中“行为”比较少，服务器负担得起。如果想节省成本可以选择不即时处理行为，等到稍空闲的时候处理，然后后台处理废除作弊用户的记录。
你的抽奖部分一定是要后台判定游戏完成才允许有这个token的用户抽，这个你懂的。
只能做混淆. 即使你混淆 也可以通过时间解除你的魔咒
推荐一篇普及的好文<对抗假人> http://www.cnblogs.com/index-html/p/frontend-based-war.html
- 用户请求网页时，在服务器生成一个唯一的
UUID - 用户提交抽奖后提交该
UUID - 服务器计算时间差，取不到
UUID或者低于一个时间阀值的肯定是作弊的
最好说还是要登录状态下，还能限制次数等
前端加密一般会被反解密出来，况且加密得客户端浏览器能解析才行。服务器端结合能保护部分。
个人建议你把js使用压缩软件进行混淆压缩，这样别人就算拿了你代码，也无法解密出来的。
还有建议是前端的js控制游戏过程，服务器端控制游戏结果。这样比较安全。
前端是没办法做到百分百加密的，如果加密了浏览器就识别不了没法解析了，所有只能做压缩混淆，这只是将多余的符号（如空格...）去掉，还有将变量名变成简单的英文字母而已，本质还是没有加密的
就算JS加密了，发起的请求也可以直接被抓包到。
所以一定要通过服务器作限制。
客户端永远是不可信任的。
抽奖逻辑放在服务端，如果有的话。
理论上是不可能的，脚本型的语言，解析器总是要解析的嘛。和天猫的一样，抽奖逻辑放服务端，只返回结果。至于用户想直接提交，这个没办法，别人不看js代码，抓包也能做到。你可以在服务端限制时间间隔，提交太快就不处理。