今天,我们来专门讨论一下微信红包的应用的做法。我们在做红包应用的时候,最常见会出现的问题是:
1、被刷
2、并发过高,产生过高费用
我们先来专门分析一下这两个问题的产生原因,然后通过一个demo案例,来给出一种相对合理的解决方法。
红包防刷的原理和解决办法
首先,被刷。被羊毛党恶意刷红包,主要有两种方式,第一种是破解了前端的加密请求后,设置固定微信的openid,向我们的服务器发送领取红包的请求,直接将红包发送给预定的openid。第二种是,将红包地址发到专门的“羊毛群”,然后由真实的羊毛党用户手动领取红包。请注意,如果我们的红包领取没有设置任何规则,比如需要通过某个预先发放的券码来兑换,任何有效的微信用户都可以领取红包的话,那第二种真实用户的“羊毛群”是无法防的,我们只能在活动时做好保密工作,并适当限制并发,限制羊毛党领取红包的速度,给我们留下应对的事件。(注意,仅仅是在微信里禁用转发,并不能防止羊毛党将红包链接发出去,因为一个H5的地址有很多种方法可以获取到,比如直接复制URL地址。)
因此,针对第二种真实用户的羊毛群,我们强烈建议在设计红包活动的时候,要设置一定的门槛,比如,用户必须先关注公众号,在公众号后台领取一个红包口令,然后通过这个口令,可以兑换真实的红包。这样,即使是真实用户,也必须要先关注公众号。或者,预先设置一批可以领取红包的用户名单,在领取的时候进行验证是否在这个白名单中。
接下来,我们重点来分析一下怎样防第一种类型的刷红包。相比第二种真实用户,第一种的危害性更大,因为刷红包的人可以预先申请好一批僵尸号,直接通过后台服务来批量把红包刷到这些僵尸号中。这种批量刷,可能在瞬间就把几千几万块的红包刷走了。而相对而言,第二种真实的羊毛群刷法,不太可能出现瞬间几秒钟就把红包全部刷完的情况,因为真实用户还是必须要完整走完我们的前端展示流程,到最后一步才能领红包。尽管他们不是我们客户的"目标用户",但依然是人类用户,而不是机器。
防止第一种机器刷的方法,主要是为我们的服务设置防线:
防线1:前端请求加密
ivx的系统前端,会自动对请求的信息进行加密,我们可以在network里看到具体的请求信息,在案例预览中,可以看到请求的明码,比如:
同样的请求,在发布时,就是加密后的数据了:
因此,正常情况下,通过查看发布后的H5,是无法获取真实的请求数据,并模拟发送请求的。但请注意,前端的加密,由于是在客户端使用js来进行,从理论上来说,还是有可能被高手破解,并获取到请求的原始信息。因此,我们不能依赖前端加密,必须要在服务后台建立更多的防线。
PS:iVX平台正在开发升级版本的前端加密方法,届时,请求加密部分会使用web assembly而不是纯js