接口防刷，痛的领悟

煎饼侠电影火了，有惊艳，但还是觉得故事发展有些莫名其妙。有梦想是对的，但是电影毕竟是电影。现实中可能要读下大鹏的书？可能吧，那时的他才算屌丝，而我一直都是。

言归正题。借此电影我们做了个抽奖活动。玩游戏拿积分。积分分为A、B、C三个等级。当然营运近一周只有3个游戏高手获得了C积分，膜拜游戏大神们。我每天早上到公司都会看自己近期所做项目日志、DB记录的好习惯。但是突然有一天到公司后，我发现数据库里突然增加了500多条C记录，而且几乎都是相同的游戏分数： 坏了，接口还是被刷了。

立即让同事将这些兑奖作废，但还是被此人兑到200多个。不爽。PM知道此事后，将此人的已兑记录作废。

做这种涉及奖品的营运活动，接口防刷是必须要考虑的。说实话，这么多年的项目积累，自己在做项目的时候也会考虑很多，力争做严谨。不想这次项目紧急，自己视野还是有限，道高一尺，魔高一丈。

项目上线前，我考虑的防刷是这样的。由于抽奖流程是玩游戏结束后分享再抽奖，两步。所以在玩游戏结束后让FE调用生成token接口，传分数，后端将分数加密生成token，写入cookie, 另外抽奖调用接口也将分数上传，相同加密策略，判断token是否与cookie中一致。然后处理兑奖逻辑，返回中奖结果，清cookie。这样可以过滤一批坏淫。而且我们规定一个用户ID只会有一次中奖机会。项目就这样急切上线了。

一周都很平静。吐槽下，毕竟是抽奖，真的没必要规定用户到了某个分数必须会中奖。因为活动涉及微信公众平台服务以及公司内部服务。这两块服务的稳定性都不是我能控制的。时常不按预期返回，比如超时等。这次因为服务不稳定不中，再玩一次吧，毕竟用户碰上两次服务不稳定的运气也是醉了。我最气运气也是超级背。

这次被刷，此时此刻这个人还在两分钟一次的刷。我赶紧采取了措施，C奖品都返回没奖。毕竟中奖概率本来就很低。给我时间想应对策略：

1. 前端请求本身带了时间戳（cache:false），与服务器当前时间对比，差1分钟就说明你根本不是真正玩家。pass掉了，因为客户端时间和服务器时间不一样啊，有的用户手机就喜欢将时间提前或延后。还记得高中时可以给表调快10分钟，为了是早起多读10分钟的书。。。

2.加IP限制。一个IP只能有2次机会。个人觉得也是OK。不过IP这东西有时候取不到。而且有人可以伪造IP。我可以将此方案加进来，但还没这么做。毕竟之前参加活动的用户并没有记录IP。

3.get换post。 毕竟我们是在微信里的项目，做过微信的可能知道，调用开发者接口要在微信客户端里打开。而在微信里模拟post请求还是有些困难的。

4.接口请求referer。生成token接口和抽奖接口，如果按正常流程走，是有严格的确定referer的。而直接调接口，referer是接口本身。

5. 彻底调低C奖品库存。之前PM说C奖品不够再加，好吧设置了10000个！还好哥及时发现被刷，要不然真被兑换了10000个。。。我将C奖品库存设置为剩余5个。最多只会被刷5个。而且毕竟中奖概率很小。

一个用户只能有一次机会，于是这个坏淫就注册了500多个微信号来关注我们，然后获取了请求记录，依次手动调用我们的俩接口，然后退出该微信号，登录新微信号，重复以上步骤。这个人看微信头像就知道不是什么好鸟：大保健广告。。。

总之，防刷经验还是要积累，实际上如果坏淫知道了我上述策略，还是可以能模拟的。不知道你们有什么更好的策略。道与魔的较量，永远不会停止。