V2EX › OneLiteCore 的所有回复 › 第 16 页 / 共 18 页

V2EX = way to explore

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

现在注册

已注册用户请登录

1 ... 8 9 10 11 12 13 14 15 16 17 ... 18

❮

❯

2024-12-12 21:47:41 +08:00

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

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

2024-12-12 20:29:45 +08:00

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

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

2024-12-12 19:05:51 +08:00

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

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

2024-12-12 19:05:01 +08:00

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

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

2024-12-12 19:02:58 +08:00

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

@StinkyTofus

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

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

2024-12-12 18:59:40 +08:00

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

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

2024-12-12 18:58:38 +08:00

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

@geelaw

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

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

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

2024-12-12 18:54:37 +08:00

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

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

2024-12-12 18:50:51 +08:00

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

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

2024-12-12 16:02:53 +08:00

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

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

2024-12-12 16:00:07 +08:00

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

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

2024-12-12 15:51:31 +08:00

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

@importmeta 项目是小工具品类的，本身不提供任何与其他用户交互的能力，所以不存在比如舆论监管审核的问题。

2024-12-08 23:55:49 +08:00

回复了 CaHCO3 创建的主题 › Apple › 乞丐版 Mac mini m4 做日常开发性能够不够？有必要上 24g 32g 嘛？或者上 pro 版 mini？

Android 开发的我表示目前用着 8G + 256G 的 M1 MacBook Air ，开发大概 10W 行代码的小项目同时运行虚拟机、微信和一些网页差不多就开始有点卡了，Mac Mini M4 的 CPU 和内存都更强所以拿来搞 Android 开发没问题。但是我问了 iOS 开发的同事，说是 256G 的硬盘空间肯定是不够的。仅供参考

2024-11-29 18:59:38 +08:00

回复了 1gzNr 创建的主题 › 分享发现 › 在数字游民社区住了一个月、随便说点"游民社区"的事儿

有具体的地址么，有点兴趣

2024-10-22 10:38:27 +08:00

回复了 fionasit007 创建的主题 › NAS › 继上次的请教， nas 最终方案来了

@Hopetree 和楼主差不多配置，8100 + 16G + 1 SSD + 2HDD + 海韵 650 的电源，待机功耗在 23W 上下，用 Ubuntu Server 系统，多开一个 Win 虚拟机功耗会到 29W ，如果用来编译 apk 的话则会上升到 50W+

2024-10-13 00:38:48 +08:00

回复了 Rust2015 创建的主题 › 编程 › 对于初学者或者生手，是从 B 站开始学还是， CSDN 或者 GitHub

建议就是——直接动手开始写，最好写点你自己感兴趣或者需要的，然后写到哪需要用到的东西再去学。最简单的一个例子是可以选择用你想学的语言去写一个图片爬虫（就是……嗯，图片的爬虫），然后试着将爬虫的公共部分重构出一个独立的模块，这样一套组合拳下来基本上会写代码了，之后看 API 和文档做东西基本问题都不会很大。

2024-10-12 13:34:09 +08:00

回复了 fionasit007 创建的主题 › NAS › 求指导，帮忙看看自主 NAS 配置合理不？

@ifwww 差点忘说了，板子的双网口是 8125B 2.5G 的方案，而 N100 的网口大多是 I226 查到可能有断流问题，这也是当时选择这个板子的原因。

2024-10-12 13:31:25 +08:00

回复了 fionasit007 创建的主题 › NAS › 求指导，帮忙看看自主 NAS 配置合理不？

@ifwww 不否认钱是广子，但是这个板子确实符合当时的需求，双网口双 M2 加 6 个 Sata ，支持 6~9 代 Intel 的 CPU 后期升级可以考虑只换一个 i7 的 CPU 进去。N100 很难达到这个拓展性或者达到的话价格和 12300T 的方案差不多了，而后者性能超标价格也超标。我需要的是一个性能还凑合的方案，其中主板要求拓展性高并且是 “全新” 的，而且当时还想玩 OpenWRT 最好还要双网口，这个是少数符合条件的方案。小厂子的主板可能确实供电用料不如大厂，但是本来负载最多也就 50W 而且我用了海韵电源，可靠性坚持到出二手换新方案应该是没问题的。

2024-10-12 13:18:51 +08:00

回复了 fionasit007 创建的主题 › NAS › 求指导，帮忙看看自主 NAS 配置合理不？

@ifwww 待机功耗确实差不多，但家用服务器不需要这么高的性能，价格也会贵一些，有这部分预算可能就选择加到主力电脑上了。而且也不是说买一次定终身，后面搬家可能再出掉之类的，本来就是折腾用的。

2024-10-12 11:36:09 +08:00

回复了 fionasit007 创建的主题 › NAS › 求指导，帮忙看看自主 NAS 配置合理不？

@ifwww 另外就是由于之前折腾过二手的配件，所以机箱和硬盘就没花钱，这部分预算就堆到了电源头上，想着以后要是这套也出问题的话电源起码还是可靠的。而且电源是 650W 的而设备待机功耗才 23W ，后期要是想要加独立显卡炼丹的话也能扛一下。综合考虑觉得电源要买好点的可以战五年，才有了这个配置。

1 ... 8 9 10 11 12 13 14 15 16 17 ... 18

❮

❯