您好。我们小程序有一个投票功能，为了防止投票接口恶意被刷，我们用了前后端md5（参数+约定key）, 加密方式。但是发现我们的小程序可能被反编译，通过我们后台日志分析，sign参数的加密方式完全正确。我们之所以认为他是恶意接口，是因为这个ip或者openid没有任何其他浏览日志，只有投票接口日志。 万般无奈之下，我们决定尝试用wx.login拿code当参数传进来。 每次投票不仅要传递sign签名参数和登陆时openid参数，还会传递code(用wx.login获取一个新的code)。服务端用code即时拿openid，并对比这个openid与传进来的openid参数是否一致。理论上，恶意刷投票接口的程序应该拿不到正确当code才对。但经过日志分析，我们升级此方案后，刷票行为大约停止了1天。然后又很快被破解。 1天后，又出现了，同ip或openid没有其他浏览日志，只有投票日志。并且投票日志中带的code参数也顺利换取了openid。 注1：我们小程序登陆之后的每个接口，都带了openid参数。所以能分析出某个openid的行为浏览日志。 注2：我们用了jwt。token字段是每个接口都有的。对方会批量注册很多账号，都是真实有效的微信号。会把我们的token和对应的openid保存起来。我们token的有效期确实也有点长。 注3：对方刷票不是说随便刷，就是一个openid肯定只能刷一票，但对方有很多openid。并且每个都是注册进来的，真实有效的。服务端有IP防刷，但对方基本上刷3，4票，换一个IP。 注4：也排出羊毛党刷单群这种，因为这种肯定有其他的浏览记录，不可能直接调投票接口。 注5: 我们后台通过行为日志肯定能分析出被刷票的作品，但不能随意取消作品，怕别人是恶意被刷。 注6: 就是不理解刷子是如何拿到正确的code。

发送模板消息有的成功，有的失败。成功率大概80%，失败的大部分返回结果都是40128 附部分有问题的formId     1538531337485     1538531337483     1538550834669     3fc7c68172511da176b1f92fc0374d5d     9ba33062badd2c03e37a9c88205e8950