芯查查开发板组装游戏公测存在的一些问题和解决

芯查查开发板组装游戏公测送Pico,Pico不算多贵,毕竟是公测,找漏洞还是主要任务。

问题

兑换ID累加而非随机

元件兑换码是15位数字,例如529772844564186,看着很安全对吧?
但是他的APP分享链接是这样的:

https://app-h5.xcc.com/mobile/friend/puzzle/give?redeemId=13

看到后面那个redeemId没有,那个是累加的,而非随机。
也就是说,可以通过穷举redeemId来达到将所有人分享的元件兑换掉。
这个漏洞太明显了,开发肯定偷懒了,而且估计没有内测直接公测,不然应该早发现了。

想起以前写的短链接网站,mysql主键一加、自增一开,长链接往里面一丢返回个自增的id,直接用自增id作短链接,不知道芯查查这个redeemId的原理是不是这样。

每人每天兑换次数无上限

这个本身问题不大,正常情况下一个分享一个兑换没什么问题,最多就是有些无聊的人会AB两个账户互相分享刷服务器资源。
但是结合上面的漏洞,一个人就可以兑换光所有兑换码,两者结合算是一个严重的漏洞了

抽奖随机程度不足问题

基本上连抽抽中的都是前一个元件,随机性差。
看着抽中这堆按键陷入沉思。

助力不方便问题

在微信中助力,打开后需要转跳到浏览器,转跳到浏览器后还要再转跳到APP,十分麻烦。

题外话

助力链接id也是累加的,不过这个没影响,就是感觉改成userid应该方便。

https://app-h5.xcc.com/mobile/friend/puzzle/get?helpId=666

解决

陌生人刷元件问题

方法一

redeemId生成方式由累加改为随机生成,结合大小写字母和数字或者多位纯数字。

方法二

限制每人每天兑换次数上限,这个只能是临时方法
因为即使限制每人每日兑换上限,依旧可以兑换陌生人分享的元件,当用户量起来后依旧是个问题。
只适合在使用方法一改代码期间临时用。

随机性问题

改进随机算法。

助力不方便问题

方法一

直接像淘宝拼多多那样在聊天框分享字符串,复制后打开APP自动识别。

方法二

基本操作同方法一,但把复制助力字符串的方法改成赠送元件的那样,打开网址后复制。

好处
  1. 能展示活动信息,估计这也是设计redeemId而不是直接使用redeemCode的原因。
  2. 直接对helpId处理后展示就好,改起来方便

半夜帮别人找BUG,自愿加班了属于是,还没工资。

不知道能不能奖我块RPI Zero 2W [滑稽]。


2022-04-13 更新

昨天的问题情况

刷元件问题

刷元件问题解决,如下为现在的链接:

https://app-h5.xcc.com/mobile/friend/puzzle/give?redeemId=647293849

相比于原来的累加,现在使用了9位随机数作为redeemId,通过遍历获取redeemCode的漏洞解决了。
9位数有约10亿个号,目前公测有842名参与活动的用户,即使第二期增加100倍也足够用了。

助力不方便问题

目前没改,毕竟只是影响体验不是漏洞,不急。

今天的新问题

助力、点赞界面设计问题

活动图如下:

示例
例如好友助力的计算方式:

拉1人 - 2次
拉3人 - 3次
拉5人 - 5次
拉6人 - 7次
拉9人 - 10次

以5人为一个循环,以此重复。
但是图中并未标明,加上文字说明“累计助力值可增加对应次数”以及图片中的“1人、3人、5人”,很容易让用户误以为每人活动期间只能让人帮忙助力5次。

新问题解决方法

助力、点赞界面设计问题

拿点赞举例,可以在前面加一个上一次循环的个数,下面的1次、2次改为+1次、+2次:
示例2
但上面的方法有个缺点,一是如果多人点赞达到了三位数,有可能放不下或者不美观。
如果把上面的次数也改成+感觉就好多了,而且左边还有足够空间放上一循环点赞数:

示例3

腾讯云活动
最后修改:2022 年 04 月 13 日
如果觉得我的文章对你有用,请随意赞赏

发表评论
使用cookie技术保留您的个人信息以便您下次快速评论,继续评论表示您已同意该条款

🎲