豆包校验验证过程说明
This commit is contained in:
@@ -10,20 +10,102 @@ WinBoLL 应用授权 AuthCenter APP。
|
||||
|
||||
#### 应用设计概述
|
||||
##### 登录认证过程
|
||||
1. 用户输入登录邮箱与服务地址。
|
||||
2. 服务器发送验证码到登录邮箱。
|
||||
3. 用户在应用里输入验证码。
|
||||
4. 应用提示用户使用空白NFC卡连接手机。
|
||||
5. 用户使用NFC卡连接手机。
|
||||
6. 应用生成应用私钥,并使用服务器公钥加密应用私钥,最后写入NFC。
|
||||
7. 加密后的应用私钥写入NFC后,应用Data数据区保存一份加密副本。
|
||||
8. 应用加密后的应用私钥副本保存后,传递应用的公钥给服务器端。
|
||||
9. 服务器端生成唯一应用ID与短Token,与应用公钥一起保存在服务器里 radis 数据区里。服务器使用 ServerUtils 类根据应用ID查询应用公钥,使用使用应用公钥加密 PONG JSON(内容为应用ID, 短Token与登录标志位)传递给应用。
|
||||
10. 应用使用Data数据区保存的应用私钥副本解密出应用私钥保存在 AuthUtils 工具类属性值里。使用 AuthUtils 类的应用私钥解密 PONG JSON 读取是否登成功的信息。
|
||||
11. 应用登录信息解析出登录成功后,应用每一分钟就使用服务器公钥加密 PING JSON(内容为应用ID, 短Token与登录标志位)传递给服务器。
|
||||
12. 服务器解密接收到的 PING JSON 信息,查询 radis 应用ID与登录标志位。登录标志位为登录并且短Token与 radis 存储的短Token一致,就生成新的短Token,再次使用应用公钥加密 PONG JSON 发送给应用。登录标志位为注销或者短Token与 radis 存储的短Token不一致,服务器端就删除应用ID对应的 radis 记录。
|
||||
|
||||
|
||||
登录鉴权+NFC绑定+心跳保活 核心校验核对表(可复制)
|
||||
|
||||
一、 前置准备阶段 校验项
|
||||
|
||||
1. 加密算法统一:全端使用RSA 2048位非对称加密,适配Android API30+与服务器兼容
|
||||
2. Redis字段完备:配置应用ID、短Token、应用公钥、用户标识、登录标志位、过期时间字段
|
||||
3. 工具类就绪:AuthUtils/ServerUtils/NFCUtils/LogUtils功能完整,可正常调用
|
||||
|
||||
二、 步骤1(用户输入邮箱+服务地址) 校验项
|
||||
|
||||
1. 邮箱格式校验:正则匹配有效邮箱,排除空值/非法字符
|
||||
2. 服务地址校验:非空且含http/https协议头,格式合规
|
||||
3. 服务连通性校验:预检服务器端口可访问,排除无效地址
|
||||
|
||||
三、 步骤2(服务器发验证码) 校验项
|
||||
|
||||
1. 服务器端:校验接收邮箱格式,记录邮箱-验证码-生成时间,设5分钟有效期
|
||||
2. 应用端:接收服务器发送回执,区分成功/失败状态并提示用户
|
||||
3. 频率限制:验证码重发间隔≥1分钟,避免恶意刷取
|
||||
|
||||
四、 步骤3(用户输入验证码) 校验项
|
||||
|
||||
1. 输入格式:强制6位纯数字,非数字输入不响应
|
||||
2. 服务器校验:核对验证码有效性+未过期,返回明确校验结果
|
||||
3. 结果反馈:弹窗提示正确/错误/已过期,流程衔接合理
|
||||
|
||||
五、 步骤4(提示放置空白NFC卡) 校验项
|
||||
|
||||
1. NFC功能检测:检测手机NFC是否开启,未开启引导至系统设置
|
||||
2. NFC卡预检:感应到卡后校验为空白卡,排除非空白卡
|
||||
3. 引导提示:持续提示NFC操作,流程不中断
|
||||
|
||||
六、 步骤5(NFC卡连接手机) 校验项
|
||||
|
||||
1. 连接状态校验:确认与NFC卡通信正常,失败可重试
|
||||
2. 卡类型适配:校验NFC卡为支持型号,排除不兼容卡种
|
||||
3. 异常兜底:多次连接失败提示硬件/卡兼容问题
|
||||
|
||||
七、 步骤6(生成密钥+加密写入NFC) 校验项
|
||||
|
||||
1. 密钥生成:应用本地成功生成RSA密钥对,失败可重生成
|
||||
2. 加密校验:服务器公钥加密应用私钥,加密结果非空有效
|
||||
3. 写入校验:加密私钥写入NFC后,读取校验与原数据一致
|
||||
4. 安全校验:全程不存储明文私钥,仅操作加密后数据
|
||||
|
||||
八、 步骤7(Data区存加密私钥副本) 校验项
|
||||
|
||||
1. 存储权限:应用具备本地存储权限,无权限引导申请
|
||||
2. 存储校验:加密私钥存入应用私有Data区,可正常读取
|
||||
3. 一致性校验:Data区副本与NFC中加密私钥完全一致
|
||||
4. 异常回滚:存储失败回滚NFC写入操作,避免数据不一致
|
||||
|
||||
九、 步骤8(应用传公钥到服务器) 校验项
|
||||
|
||||
1. 公钥完整性:应用公钥格式符合RSA规范,无残缺
|
||||
2. 关联绑定:提交公钥携带用户邮箱,服务器绑定用户-应用公钥
|
||||
3. 传输兜底:公钥传输失败支持自动重试,网络异常提示用户
|
||||
|
||||
十、 步骤9(服务器生成ID/Token+加密返PONG) 校验项
|
||||
|
||||
1. 存储校验:服务器存入Redis(应用ID+短Token+应用公钥+邮箱+登录标志位true),设初始过期时间
|
||||
2. 公钥查询:ServerUtils可正常查询到对应应用公钥
|
||||
3. 加密校验:应用公钥加密PONG JSON,加密成功后返回
|
||||
4. PONG内容:包含应用ID、短Token、登录标志位,字段无缺失
|
||||
|
||||
十一、 步骤10(应用解密+确认登录) 校验项
|
||||
|
||||
1. 私钥解密:从Data区读取加密私钥,临时解密为明文(仅内存存储)
|
||||
2. PONG解密:明文私钥解密PONG JSON,数据完整无乱码
|
||||
3. 登录判定:解析登录标志位为true则登录成功,反之提示失败
|
||||
4. 安全校验:登录确认后,立即清空AuthUtils中临时明文私钥
|
||||
|
||||
十二、 步骤11(应用分钟级发加密PING) 校验项
|
||||
|
||||
1. PING内容校验:JSON含应用ID、短Token、登录标志位true,无字段缺失
|
||||
2. 加密校验:服务器公钥加密PING数据,加密有效再发送
|
||||
3. 定时校验:定时任务稳定(每分钟1次),网络差可延迟30秒重试
|
||||
4. 兜底校验:单次发送失败,缓存请求下次优先重发
|
||||
|
||||
十三、 步骤12(服务器处理PING+响应) 校验项
|
||||
|
||||
1. PING解密:服务器私钥解密PING JSON,可正常解析核心字段
|
||||
2. Redis查询:ServerUtils按应用ID查询到有效Redis记录
|
||||
3. 双重核心校验:登录标志位=true + 短Token与Redis存储一致(双条件同时满足)
|
||||
4. 校验通过:生成新短Token、更新Redis记录+过期时间、加密新PONG返回
|
||||
5. 校验失败:删除对应Redis记录、返回登录失效回执
|
||||
6. 异常兜底:解密失败/数据残缺,直接判定校验失败并清理Redis记录
|
||||
|
||||
十四、 全流程通用校验项
|
||||
|
||||
1. 网络兜底:所有跨端交互支持重试,网络恢复可续传
|
||||
2. 异常续跑:应用中途退出,重启可从最近完成校验步骤继续
|
||||
3. 安全兜底:加密/解密/读写失败不泄露明文密钥,支持流程回滚
|
||||
4. 日志兜底:关键步骤均有LogUtils日志输出,可追溯问题
|
||||
5. 权限兜底:涉及NFC、存储权限,均有引导申请流程
|
||||
|
||||
#### Gradle 编译说明
|
||||
调试版编译命令 :gradle assembleBetaDebug
|
||||
阶段版编译命令 :bash .winboll/bashPublishAPKAddTag.sh appbase
|
||||
|
||||
Reference in New Issue
Block a user