安全说明

这个网站不是给别人部署 AuthGuard 源码的，它的真实定位是：

向软件开发者提供可付费调用的网络验证能力。

因此这里的安全说明，不讨论“你怎么部署本站”，而是讨论：

你如何安全调用接口
你的软件如何安全接入验证系统
你的付费授权、设备绑定、在线心跳如何避免被滥用

一、鉴权边界

当前系统存在两层鉴权：

1. 软件验证层

用于软件客户端或验证逻辑调用：

/api/verify/init
/api/verify/login
/api/verify/card-login
/api/verify/heartbeat
/api/verify/status
/api/verify/unbind

这一层的重点是：

用户身份是否有效
卡密是否有效
设备是否超限
授权是否过期
在线状态是否正常

2. 开发者后台层

用于开发者控制台或管理员控制台：

/api/auth/*
/api/users/*
/api/applications/*
/api/usdt/*
/kedaya 相关管理接口

这一层的重点是：

开发者账号登录
应用管理
用户管理
充值与结算
管理员级操作审计

二、计价与支付安全

当前业务规则已经明确：

计价单位：RMB
结算单位：RMB
支付媒介：USDT

也就是说：

前台看到的余额、价格、结算结果应该统一是 RMB
用户实际链上支付时使用 USDT
系统在订单确认时按实时汇率将 USDT 折算为 RMB 入账

安全上需要注意：

不能把 USDT 支付金额直接当作系统余额单位
不能让前台价格单位和后台结算单位分裂
汇率来源要可控，并有失败回退策略
订单确认必须基于链上校验，而不是只看前端提交

三、设备与授权安全

网络验证系统最核心的不是页面，而是设备与授权控制。

当前系统应重点保证：

同一账号的设备上限可控
解绑必须经过验证接口，而不是前端直接改状态
心跳接口用于判断在线与有效性
授权状态查询必须能识别：
- 正常
- 已过期
- 已封禁
- 设备异常
- 单码失效

如果这些边界没有锁住，再漂亮的 UI 都没有意义。

四、黑名单与风控

黑名单应以 开发者账号 或 业务主体 为核心，而不是混乱地在不同页面同时使用 UID、开发者账号、历史代理字段。

正确方向：

管理员黑名单：开发者账号语义
软件业务黑名单：按应用下的用户/设备语义管理
不同层级的黑名单不能混为一谈

风控重点：

管理员黑名单不要继续污染成 UID 黑名单
软件用户封禁与开发者封禁要分层
黑名单入口必须统一，避免后台出现多套规则

五、接口调用建议

如果你是接入方，建议按下面顺序接入：

软件初始化
用户登录 / 单码登录
取状态
在线心跳
解绑

如果你是平台运营方，建议先保证：

充值链路真实可用
RMB 余额与结算一致
/kedaya 是唯一管理员入口
开发者、黑名单、定价、区块链配置都从同一后台收口

六、当前产品安全重点

现阶段真正重要的不是“如何部署项目”，而是下面这些：

软件验证接口是否稳定
用户状态是否可控
设备绑定是否可靠
充值到账是否真实
余额入账是否和计价单位一致
管理员操作是否统一收口到 /kedaya
文档是否只写真实存在的接口

这些才是一个“软件加密付费网络验证系统”的安全核心。