这是一个创建于 290 天前的主题，其中的信息可能已经有所发展或是发生改变。
又是我，上次发完“一种基于邮箱的用户付费系统构想”的帖子后和大家沟通受益良多，之后便启动开发了，但是很快又发现了些问题：
使用微信 openid 作为用户唯一标识然后接入微信支付，付款的用户登录微信即激活，这个方案按理说还是挺完美的，但是有一个致命的问题就是用户只能够在其安装并登录了对应用户的设备上才能激活。假如用户有主力机、备用机和一个平板的话，那他大概率只会在主力机上安装微信，备用机和平板就没办法激活了。也就是说这个方案不存在多设备激活的可能性。
当然做比如使用被微信激活的设备生成二维码或者激活码来激活次要设备再限制登录之类的，但是这个有点奇葩了，用户估计很难接受。另外假如后续接入支付宝的话这套流程又很难兼容。综上感觉除非是和微信生态强绑定的项目，否则不太适合这套方案。
另一个方案是使用激活码，直接使用订单号作为激活码然后限制登录，允许二次交易。虽然可能存在泄露激活码然后被他人盗用的问题，但这个是用户的责任开发者可以不用管。这个算是成熟的方案了，没有什么太大的问题。
这次发帖的话主要还是想再探讨一下用邮箱作为认证的可行性，对比上次改动如下：
1.用户首次打开 APP 时生成并持久化一个 UUID 作为唯一凭证，在登录时将 UUID 、设备信息和邮箱发送到后台
2.后台将传上来的信息保存到数据库，然后加密信息发送邮件到用户邮箱
3.用户点击邮箱中的超链接，后台解密验证后在数据库里标记设备登录，并在网页中通知用户回到 APP 刷新状态
4.APP 状态分为“未登录可以查询登录状态或者立即登录”、“已登录可以退出登录或点击立即激活”和“已激活”三种状态。用户用持久化的 UUID 查询登录状态则进入“已登录”的状态
5.已登录用户点击立即激活，如果后台未查到购买记录则发起购买，付费成功后 APP 自动重新询问激活
6.如果查询到购买记录则新增一行激活记录并返回激活凭证保存到 APP 本地，并作废旧的激活记录以限制设备数量
7.如果连登录记录都查不到的话则踢出用户回退到未登录的状态
8.已激活的用户打开 APP 时定时去询问，如果本地的激活凭证过期则回退到已登录的状态
对比之前的流程省略了用户复制邮件内容的过程，能够解决微信登录多设备难激活的问题，之后假如对接支付宝也不会有很大的兼容问题，要说复杂肯定是比纯激活码方案要复杂的，这里先探讨可行性。目前能够想到的可能会遇到的问题：
1.需要搭建邮件服务器，虽然听说可以找 163 之类的托管一个邮件域名，但毕竟还是多引入了一个环节，可能存在邮件被用户邮箱封禁的问题
2.接口需要做一定的频率保护，针对同一个 UUID 或者同一个邮箱地址限定比如只能一分钟发一次邮件
3.用户可能会要求更换邮箱但保持购买记录，这个只能联系开发者手动处理了
4.用户可能卖掉第二第三设备的激活名额但是之后又想反悔，需要解除某些设备的绑定，这个只能联系开发者删掉邮箱的登录记录
大家有什么意见或者建议都可以提出来，这里先提前感谢大家了！
 | 1 InDom 290 天前 1. 用户自己会看垃圾箱的 3. 修改邮箱, 固定流程了吧,先给旧邮箱发,确认后改成新的. 4. 无论从哪个角度看都不应该支持 |
 | 2 OneLiteCore OP @InDom 3.修改邮箱。最开始构想这个方案的时候就是不想自己维护一套账号系统所以想要省略诸如找回密码的步骤的。人工处理的话起码先确定收件人，然后要求对方提供购买的微信截图，邮箱地址和截图中的付款订单号对得上就确定是原主，此时帮他人工修改无妨。当然用户也可能会这个过程中进行二次售卖，只不过加上人工的话流程会繁琐很多。 |
 | 3 forty 290 天前 这种表述，还是适合画个流程图 |
 | 4 Repobor 290 天前 "使用微信 openid 作为用户唯一标识然后接入微信支付，付款的用户登录微信即激活，这个方案按理说还是挺完美的，但是有一个致命的问题就是用户只能够在其安装并登录了对应用户的设备上才能激活。假如用户有主力机、备用机和一个平板的话，那他大概率只会在主力机上安装微信，备用机和平板就没办法激活了。也就是说这个方案不存在多设备激活的可能性。" 其实还可以通过扫码登陆的方式来识别的，可以参考应用“存储空间清理” |
 | 5 renmu 290 天前 via Android 这就是一个邮箱登陆以及保证只有单设备登录，有什么创新吗? |
 | 6 OneLiteCore OP @Repobor 这套机制对开发和用户来说似乎都不是很友好 |
| 7 OneLiteCore OP @renmu 确实没什么创新啊，只是想看看这种操作有没有可行性 |
| 8 renmu 289 天前 via Android @OneLiteCore 你说可不可行那肯定是可行的，这可不就是普通 c 端鉴权流程。 但是本地激活软件，我觉得要处理的是如何防止用户破解，用户要离线使用不能轮询怎么办，hook 掉你的轮询请求怎么处理，有多个激活名额，用户共用怎么办 |
| 9 OneLiteCore OP @renmu 我是做 Android 原生开发出身的所以对后台和前端的开发都不甚了解，所以发出来问问看看这个操作是否可行。关于防止用户破解的： 1.用户要离线使用怎么办。用户不可能一辈子不联网，另外客户端本身没有什么有价值的东西，用户愿意一直离线使用也无妨。 2.Hook 掉轮询。用户有这个本事直接 Hook 判断是否已激活的方法就行了，没必要多此一举。 3.有多个激活名额。我看竞品的设计是一个激活账号只允许 3 台设备使用，这里就直接抄了。超出名额的部分的限制在后端做。 |
 | 10 jeesk 289 天前 via Android @OneLiteCore 双向 tls 加上 root 检测， 最加上 keystore 加密， 内容要加密， 已经拦截了 %99 的人了， 加上服务端验证， 顶多让人共享软件的使用权。 |
| 11 jeesk 289 天前 via Android 没有任何人能够阻挡别人破解 |
| 12 OneLiteCore OP @jeesk 目前的做法是在使用 https 的基础上对 post 请求的 body 用 aes 加密，然后 aes 的 key 用服务器的公钥加密扔 header 里面，后台也用一样的方法加密 body 然后用客户端的公钥加密 key 扔 header ，这个是双线 TLS 么？我是 Android 原生开发出身的所以对这些术语并不是非常熟悉。Header 里面同时带有 aes 加密的设备时间戳和 UUID ，时间戳和服务器允许若干分钟的时差，UUID 后面可以做频率限制。客户端也在 so 文件里面做了验证了。 |
| 13 OneLiteCore OP @jeesk 本来就是一个非常小众的小工具，就算被破解也没什么太大的问题，用的人这么少连破解版都比较难以传播。现在主要在头疼国内后台的开发上。 |
Select Language