 lovife
|
15b819746b
|
feat(mp): M3-01 门禁核验（名单是闸门）
M3 的第一块：学生必须先过名单核验，才能开始填报任何东西。
交付：
· POST /api/v1/mp/roster/match（§5.4）—— 姓名+证件号与名册匹配，命中才放行并绑定
· common/util/IdCardUtil —— 身份证校验位（三态裁决）
· support/ClientIp —— 取真实调用方 IP（限流用，X-Forwarded-For 第一段）
· module/roster/entity/CollectRoster —— 名册实体（M2 会继续用）
四条守住的规则：
1) 失败提示必须统一（40007），不区分"姓名错"还是"号码错"。
分开提示等于交付了一个身份证号枚举器：用任意姓名+目标号码试，
若提示"姓名不对"就说明号码在名单里，一个个试就能把全校号码试出来。
这不是体验取舍，是安全底线。E2E 专门断言两种失败的 msg 字符串完全一致。
2) 绑定并发安全：UPDATE ... WHERE bind_user_id IS NULL + 看影响行数。
不要改成"先 SELECT 判空再 UPDATE"——中间有窗口，两人会同时通过检查，
后绑的人静默覆盖先绑的人，而先绑的学生之后再也进不去。
E2E 用两个线程同时冲同一行，断言"恰好一个成功、一个 40072"（实测 [0, 40072]）。
3) 证件号明文只在 match() 里出现一次，失败日志只记 HMAC 与 uid（日志被翻出来
同样是泄露）；响应里永远只有 idCardMask，E2E 断言整个响应 JSON 不含明文。
4) 已绑定自己的人重复核验是幂等的 —— 学生刷新页面不该看到"该信息已被登记"。
IdCardUtil 的价值在三态而不在对错：
真实数据集实测：名册 28 人校验位全通过（可信基准）；某两个学生的文件名证件号
校验位失败（确定是号码错，可自动改正）；另一学生的两个号码都通过（是两个真人，
串档实锤，必须人工介入）。后两种看起来都是"号码对不上"，处理策略却完全相反——
一个能放心自动修，另一个自动修就是把两个真人的材料合并。区分它们的唯一办法
就是校验位。所以对外暴露 Verdict{VALID,CHECKSUM_FAILED,MALFORMED} 而非 boolean。
1900 年下界是业务判断，不是国标要求：网上流传的"示例有效身份证号"里有一批
出生年份在 1800 年代（如常被引用的 440524188001010014 → 1880 年），它们校验位
合法但不可能是认定考生。只算校验位会把它们判成 VALID。这个坑写 E2E 时真踩到了。
E2E 怎么拿 token：门禁要求已登录的学生，而登录（/mp/login）需要真实的 wx.login
code，脚本拿不到。所以用 dev 配置里的 JWT 密钥自己签一个 MP token（HS512，
claims 与 JwtService.issue 同构）—— 与 e2e-m0 用 dev RSA 公钥加密登录密码是同一类
做法：用开发配置里的凭据手搓测试夹具，不是绕过认证逻辑。prod 密钥不在仓库里，
这个手法自然失效。顺带：读配置要读两个文件，issuer 在主 application.yml 里，
只读 dev 会漏掉它，而症状是 401，完全指不到"配置没读到"。
回归抓到我一条脆断言：
e2e-m1-qrcode.py 的"token TTL 是 7000 秒"在连续第二次运行时失败（TTL=4633，
正好是两次运行的时间差）——它假设 token 是刚取的，实际沿用了缓存。
已改成"先清缓存强制重取，再断言 TTL∈[6900,7000]"，连跑两次都稳定通过。
教训与前面几次同类：断言要确定性地反映被测行为，而不是碰巧在某种顺序下通过。
已知缺口（写进交接摘要）：
· /mp/login 未做：它需要真实 wx.login code，脚本测不了，只能在小程序里测，
下一轮连同小程序核验页一起做。
· 形近字候选（FR-504c）未实现，needConfirmName 恒为 false。
· 名册导入未做（M2），E2E 用 SQL 直接造名册行。
· 小程序端还没有核验页（落地页的「开始填报」目前是明确的"开发中"提示）。
验收：e2e-m3-gate.py 29/29（含并发绑定与限流）；
九条 E2E 合计 418 项断言全通过。
|
2026-09-29 10:46:21 +08:00 |
|
|
lovife
|
87ece5a971
|
feat(frontend): 管理端改用 Gi Admin Pro 框架 + 腾讯云主题
前端此前只有本地实现、从未入库，本次首次纳入版本管理。
框架切换
· 以 Gi Admin Pro（Vue3 + Vite + TS + Arco Design Vue + Pinia）为底
· 剥离 14 个演示页面目录 / 121 个文件（demo 28、file 20、form 19、system 18…）
· 依赖 dependencies 35 → 19，devDependencies 31 → 27
· 保留框架核心：layout、Gi* 组件库、hooks、权限指令、错误页、登录页
主题：腾讯云 / TDesign 官方色板
· 主色 #0052D9（腾讯蓝）、成功 #00A870、警告 #ED7B2F、危险 #E34D59
· 页面底色 #f3f3f3、文字 rgba(0,0,0,90/60/40/26%)
· 覆盖 Arco 底层色板 + 显式语义别名（primary/success/warning/danger/link/neutral）
· 三个改了不生效也不报错的坑已记入注释：
1) Arco 色值是逗号分隔 RGB 三元组，不是 #RRGGBB
2) Arco 把色板定义在 body 而非 :root，必须写 `:root, body`
3) setting.json 的 themeColor 会以内联样式写进 body，优先级高于样式表
对接后端（三处契约差异在 @/utils/http 统一适配）
· 响应信封 {code,msg,data} → {code,success,message,data}
· Token 头 token → Authorization: Bearer
· 分页 {list,total} → 补一份 records，list 原样保留
· 40101 → 登录页；登录密码 RSA 加密（公钥走 /auth/public-key，轮换无需重建前端）
· 路由：后端只下发菜单键，前端在本地路由表上过滤（有哪些页面归代码，谁能看归后端）
已实现页面（浏览器实测通过）
· 登录：RSA 加密 + 自适应验证码/租户码 + 账号锁定提示
· 工作台：真实数据（组织 6 个 / 角色 1 个 / 权限 25 项）
· 组织架构：三级树 + CRUD + 占用校验
· 租户管理：开通租户 + 初始密码只显示一次的强确认
· 待建页：未实现菜单显示所属里程碑
· 权限菜单：学校管理员看不到「租户管理」
视觉资产按腾讯云主题重做
· logo.svg（渐变圆角方 + 填）、favicon.svg（小尺寸做减法）、login-hero.svg（材料归集）
· 登录页点阵纹理走主题变量，换主色自动跟随
· 文案改为产品实际能力：自动改名 / 强制压缩 / 隐私保护
清理模板遗留（约 17MB + 三处外部依赖）
· 百度统计脚本（上报到 gi-demo 作者的统计账号）
· 用户菜单「项目地址」（跳转模板作者的 Gitee 仓库）
· 两份 8.8MB mp3、388KB favicon.ico、57KB 模板插画、未引用字体与 loading.gif
· 「个人中心」指向已删除的 /system/account（点了 404）
· 头部头像在无 avatarUrl 时渲染成裂图 → 改为姓名首字兜底
后端修复
· 新增 GET /auth/public-key（前端加密登录密码用）
· DataSeeder.ancestor_path 生成错误：子节点本该是 /16/17/ 却写成 /17/
该字段是「按院系统计」的索引，错了会漏人/多人且不报错 —— 改为从库里读父节点路径
· seedDemoOrgs 曾放在租户作用域外 + admin 早退分支之后，导致启动失败 / 永不执行
· 示范租户补一套三级组织树（1 学校 / 2 院系 / 3 班级），供界面演示
|
2026-09-28 20:49:55 +08:00 |
|