V2EX › OneLiteCore 的所有回复 › 第 21 页 / 共 23 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

1 ... 13 14 15 16 17 18 19 20 21 22 ... 23

❮

❯

2024 年 12 月 24 日

回复了 OneLiteCore 创建的主题 › 程序员 › 另一种基于邮箱的用户认证系统构想

@renmu 我是做 Android 原生开发出身的所以对后台和前端的开发都不甚了解，所以发出来问问看看这个操作是否可行。关于防止用户破解的：

1.用户要离线使用怎么办。用户不可能一辈子不联网，另外客户端本身没有什么有价值的东西，用户愿意一直离线使用也无妨。
2.Hook 掉轮询。用户有这个本事直接 Hook 判断是否已激活的方法就行了，没必要多此一举。
3.有多个激活名额。我看竞品的设计是一个激活账号只允许 3 台设备使用，这里就直接抄了。超出名额的部分的限制在后端做。

2024 年 12 月 24 日

回复了 OneLiteCore 创建的主题 › 程序员 › 另一种基于邮箱的用户认证系统构想

@renmu 确实没什么创新啊，只是想看看这种操作有没有可行性

2024 年 12 月 24 日

回复了 OneLiteCore 创建的主题 › 程序员 › 另一种基于邮箱的用户认证系统构想

@Repobor 这套机制对开发和用户来说似乎都不是很友好

2024 年 12 月 24 日

回复了 OneLiteCore 创建的主题 › 程序员 › 另一种基于邮箱的用户认证系统构想

@InDom

3.修改邮箱。最开始构想这个方案的时候就是不想自己维护一套账号系统所以想要省略诸如找回密码的步骤的。人工处理的话起码先确定收件人，然后要求对方提供购买的微信截图，邮箱地址和截图中的付款订单号对得上就确定是原主，此时帮他人工修改无妨。当然用户也可能会这个过程中进行二次售卖，只不过加上人工的话流程会繁琐很多。

2024 年 12 月 22 日

回复了 COW 创建的主题 › 程序员 › 2024 年了，无聊想尝试下 neovim

尝试过后来觉得自己维护一套自己习惯的配置需要耗费巨大的精力，如果不是真的喜欢折腾的话有点得不偿失。就我自己折腾过后的建议是，这玩意更适合配置 iterm2 或者 Windows Terminal 等支持下拉模式的命令行工具做一个全局随时呼出的记事本，并配合 Git 或者其他管理工具来同步备份笔记数据，偶尔改改系统配置文件复制点东西之类的。轻量级的开发无论是远程还是本地用 VSCode 都足够搞定，重量级的还是直接上 IDE 吧。

2024 年 12 月 13 日

回复了 OneLiteCore 创建的主题 › 程序员 › 一种基于邮箱的用户付费系统构想

@baobao1270

1. 小工具基本没办法防止反编译啊，而且用户有这个能力的话那此时也就不是操心账号和付费系统的时候了
2. 抓包的话用 https 里面套了一层 RSA 加密，客户端和服务端互相持有对方的公钥的那种
3. 综合下来就是用微信登录和订单号作为记录最靠谱，还能预防二次转卖的问题

2024 年 12 月 13 日

回复了 OneLiteCore 创建的主题 › 程序员 › 一种基于邮箱的用户付费系统构想

@ysy950803 看了眼通知滤盒，这个更简单连激活码都不做，直接用订单号作为激活码了。感谢提点，很有启发！

2024 年 12 月 13 日

回复了 OneLiteCore 创建的主题 › 程序员 › 一种基于邮箱的用户付费系统构想

@baobao1270
1. 这个没毛病，赞同。
2. 小工具品类东西都在客户端上，后台也不提供服务的情况下登录了也没有更多功能，所以才考虑简化的。看了眼 logto 似乎能解决部分问题不过还是感觉略复杂，打算接微信登录算了。
3. Android 开发里面没听说过 ASM ，这个是前端的东西吗？
4. Mitm 也没听说过。
5. 国内基本是微信当邮箱用的，所以直接接入微信生态似乎是一个更好的选择

2024 年 12 月 12 日

回复了 OneLiteCore 创建的主题 › 程序员 › 一种基于邮箱的用户付费系统构想

@yuhaofe 发送随机验证码的话，客户端拿到验证码还是需要去询问后台是不是这个验证码，直接用在客户端用后台的公钥去验证签名可以省略一步。不过看了上面老哥的讨论，觉得要么直接用微信登录，要么就直接激活码更合适点。

2024 年 12 月 12 日

回复了 OneLiteCore 创建的主题 › 程序员 › 一种基于邮箱的用户付费系统构想

@yueji 是后台通过 smtp 发送邮件到用户的邮箱，抓包没办法抓服务器的包的吧，用户在这个过程中能够看到的是后台用私钥签名的值。这样客户端本地也持有邮箱和 UUID 可以直接算 MD5 并验证签名。

2024 年 12 月 12 日

回复了 OneLiteCore 创建的主题 › 程序员 › 一种基于邮箱的用户付费系统构想

@yuhaofe 为了规避发送短信所需要的成本，短信显然不是免费的，同时也为了规避自己搭建一套账号系统，是出于运行和开发成本的考量。但是按照上面的讨论得出的结果就是，直接上微信登录似乎是一个更好的选择，或者不在乎用户二次交易的话直接用激活码更合适一些。

2024 年 12 月 12 日

回复了 OneLiteCore 创建的主题 › 程序员 › 一种基于邮箱的用户付费系统构想

@sampeng 这个经验很有价值，感谢提点！

2024 年 12 月 12 日

回复了 OneLiteCore 创建的主题 › 程序员 › 一种基于邮箱的用户付费系统构想

@yuhaofe 确实，直接上激活码可以省略一层操作，你说的很对。加一层邮箱的话只不过让用户忘记激活码这个过程省略了而已。

2024 年 12 月 12 日

回复了 OneLiteCore 创建的主题 › 程序员 › 一种基于邮箱的用户付费系统构想

@StinkyTofus

1. 邮箱确实不是必选项，但是比起用手机号和验证码来说更省钱，短信验证码可不是免费的。

2. 如果你都能 HOOK 掉 UUID 的话，直接本地激活就行了，或者有这个能力直接破解 APK 都更容易些。

2024 年 12 月 12 日

回复了 OneLiteCore 创建的主题 › 程序员 › 一种基于邮箱的用户付费系统构想

@SenLief 那也要确保用户填写的邮箱是他本人的邮箱，如果用户随便填写一个邮箱然后付费激活了的话，还是需要人工联系提交交易 ID ，然后开发者手动去退款之类的。

2024 年 12 月 12 日

回复了 OneLiteCore 创建的主题 › 程序员 › 一种基于邮箱的用户付费系统构想

@geelaw

UUID 的作用是唯一标识，因为获取 IMEI 之类的设备表示不太符合隐私政策。其实只要是随机的没有碰撞问题的 ID 都行，UUID 只不过是在 Android 原生开发里面最容易获取罢了。这样和邮箱关联在一起，可以知道 UUID 和邮箱的持有人是对应关系，同时也可以用来限制登录设备数量。

UUID 是要保存在客户端本地的，用 MMKV 框架做持久化就行了最多本地再加密一下，不需要用户手动操作。

发送到邮箱里面的数据也可以不用用户复制，而是使用 DeepLink 之类的方式拉起应用，以减少用户的操作。

2024 年 12 月 12 日

回复了 OneLiteCore 创建的主题 › 程序员 › 一种基于邮箱的用户付费系统构想

@ysy950803 用微信登录来做唯一凭证是一个不错的想法，毕竟都用微信支付了肯定有微信号，感谢提点！最开始设想用邮箱的话有一个目的就是将用户的购买凭证和付款方式分离开来，这样比如类似俄罗斯这种用不了 Google 支付以及微信支付的地区也能够通过手动转账，然后人工将邮箱写进数据库的方法来完成流程。

2024 年 12 月 12 日

回复了 OneLiteCore 创建的主题 › 程序员 › 一种基于邮箱的用户付费系统构想

@monkeyk 指纹和扫脸只能认证用户是这个设备的主人的吧，用户换设备激活的话没办法迁移。本质上这个就是生成一个用户唯一凭证以此来代替账户系统而已，邮箱恰巧是个人拥有并且可以作为数据交换的方式。

2024 年 12 月 12 日

回复了 OneLiteCore 创建的主题 › 程序员 › 一种基于邮箱的用户付费系统构想

@ltaoo1o 标题确实不太贴合内容，不好意思。主要还是想要了解下这套逻辑是否可行，是否存在着明显的漏洞问题之类的，如果熟悉这方面知识还望赐教。

2024 年 12 月 12 日

回复了 OneLiteCore 创建的主题 › 程序员 › 一种基于邮箱的用户付费系统构想

@timethinker 哈哈哈，看了下面的回复才发现确实这个标题起的不是很好

1 ... 13 14 15 16 17 18 19 20 21 22 ... 23

❮

❯