社区各种送码，这个激活码你们都是怎么做的？

[YiXinCoding]

有没有完整的开源方案或者教程啊？

比如这个完整流程：

用户付费 -> 生成激活码 -> 自动发码 -> 客户端输入激活码 -> 绑定机器码 -> 服务端确认 -> 完成激活

每个独立开发者都要造一套自己的轮子么？

[YiXinCoding]

有这种教程，但这部分工作量有没有可能省下来： https://juejin.cn/post/6844903857080778766

[fruitmonster]

“服务器端生成验证串的地方使用密钥对机器码进行签名，然后在客户端只需要用公钥进行签名验证，就可以判断验证串是否有效。”

没太明白， 服务端对激活码进行了签名，只有客户端的公钥能验证，那客户端被逆向了，拿到了对应的公钥，那不也有问题了么

[jeesk]

@fruitmonster 如果能操作设备内存, 那么怎么都不安全.
还是建议在应用第一次启动的时候生成 keystore, 然后携带这个 keystore 加解密. 即使 http 被监听也没啥, 解密不了.

[YiXinCoding]

@fruitmonster 防君子不防小人啊。替换机器码，替换公钥，也都有可能。编译后藏得深一点，多加几处校验。只能这样了。

[skinny]

前面你们说的，这就是为什么各种 App 都要想方设法的检测 Root 、虚拟机、提权、防篡改、App 签名，不然不可能安全的。

[fruitmonster]

假设有一个登记的接口暂且叫`小登`，每天限量 10 个，登记信息需要身份证 A 、登记码 B

登记码 B 来暂且叫`老登`，想要调用小登接口，必须要从`老登`来获取登记码 B ，登记码每天都是不同，都会更新

而 `老登`接口又不能随便获取，会验证签名、Token ，恰恰`老登`接口在微信小程序里，逆向，反编译不了，拿不到 token 和签名的计算方式，

那是不是这个登记接口`小登`和`老登`就是安全的了？

[FaiChou]

确实比较麻烦。做移动端开发可以用系统的内购，比如苹果内购。但会有很多 fee 。

自己部署个发卡网站，自己后台验证确实挺麻烦。

我也想蹲一个解决方案。