|
|
706ff2507e
|
feat(admin): 新增选手信息编辑接口 PUT /api/admin/contestants/:id(R108)
此前 contestants 表只有 Excel 导入一个写入口 —— 证件号/姓名/手机号录错后
改不了也删不掉。本提交新增受控编辑通道。
service.updateContestant(id, payload):
· 白名单仅 name / phone / id_number;白名单外字段(group / 成绩类 /
password / test_flag / team_id / activated)显式 400 拒绝,非静默忽略
(静默忽略会让管理员误以为改成功)
· id_number 判据复用 lib/idCard.js(与导入通道同源):长度 != 18 拒绝;
校验位不符 / 含非法字符 => 放行 + warnings[](生产库现存正式考生中
即有 4 条校验位不符,硬拦截会造成合法数据改不动)
· 唯一性冲突 => 409
· 改号连带重算口令:导入时 password = sha256(证号后 6 位),而证号即登录
账号 => 不同步重算则学生「账号对、口令错」(UI 上看不出来)。4 分支:
测试数据 / 已激活 / 已是 bcrypt => 不动 + 告警;未激活派生值 => 重算
· 同值提交(含仅大小写差异)不发 UPDATE
· 审计日志证号脱敏、口令只记「是否重算」
controller.updateContestant:映射 400/404/409。
router:新增 PUT /api/admin/contestants/:id(adminAuth)。破坏面定级 =
非破坏性(白名单编辑 + 可逆 + 带审计)=> 未登记 DESTRUCTIVE_ENDPOINTS.json。
判据:scripts/verify_update_contestant.mjs(42 判据 + 4 变异自证)。
行号漂移纪律:controller/admin.js 被 3 个脚本按行号引用(:33/:1556/:1570)
=> 新增一律追加文件末尾,改后 3/3 未漂移。
|
2026-10-12 17:20:41 +08:00 |
|
|
|
76ac1c7b6b
|
security(config): 四个同族兜底缺陷一次收口 —— APP_KEYS / 弱口令 / IPv6 兜底 / 本地生产密钥同值(R106-D6~D9)
共同根因(R104 结论的延续):**同族问题各自实现必然漂移**。
本仓 DB_PASSWORD 与 JWT_SECRET(R105-D1)已统一为「缺凭据明确失败」,
但同族的另三处仍停在「可预测的公开兜底」上,另新增一处跨环境密钥同值。
D6 · APP_KEYS 派生兜底(原 config.default.js:157)
原:const DEFAULT_APP_KEYS = appInfo.name + '_competition_website_secret_key_2026';
config.keys = process.env.APP_KEYS || DEFAULT_APP_KEYS;
「派生」不等于安全:由 appInfo.name 可推算 ⇒ 等价于「Cookie 签名密钥公开
⇒ 任何人可伪造已签名 Cookie」。收口到 _secret.cjs 唯一解析入口:
· scripts/_secret.cjs 抽出通用 _loadSecret(),新增 loadAppKeys()
(① env → ② scripts/.creds.local.json:app_keys → ③ 明确失败,⛔ 无兜底)
· 生产安全守卫移除 config.keys === DEFAULT_APP_KEYS 比对分支(已无可比兜底值)
· scripts/_creds.py 与 .creds.local.example.json 同步键面(两侧同源,永不漂移)
D7 · 生产弱口令兜底(原 config.default.js:176)
原:config.testDefaultPassword = process.env.TEST_DEFAULT_PASSWORD || '123456';
而 deploy/.env.production 的 TEST_DEFAULT_PASSWORD 一直是**注释状态** ⇒ 生产
实际取到的就是弱口令 '123456'。一旦走到「批量写默认口令」的路径(重置测试数据 /
显式 testFlag=true 的导入)会批量设弱口令 —— 属**静默弱口令**而非明确失败。
修法:生产(config.isProduction)未显式注入 ⇒ 置 null;使用点改走新增的
app/lib/passwordPolicy.requireTestPassword() 明确失败。测试环境语义逐字不变。
D8 · 本地 DB 兜底 host 引发 IPv6 建连超时(原 config.default.js:217)
原:host: process.env.DB_HOST || 'localhost'。Node >= 18 的 verbatim DNS 可能把
localhost 解析到 ::1,而本机 MariaDB 只听 IPv4 ⇒ **建连 ETIMEDOUT**(不报 1045、
不报 ECONNREFUSED),现象是「后端启动卡在 DB」,极易误判为「服务没起来」。
且本仓 scripts/_db.cjs:43 的兜底早已是 '127.0.0.1' —— 同子系统两套默认值必然漂移。
修法:兜底改为 IPv4 字面量(生产显式注入 DB_HOST ⇒ 逐字不变)。
配套(config.local.js 为 gitignored 本地文件,不入库):补 host/port 覆盖 ——
「第二道保险」原本只保账号/口令,反而漏掉了真正会出问题的连接目标。
D9 · 本地 dev 与生产共用同一 JWT/APP_KEYS(loadDeployEnv)
非生产跳过清单原本只含 DB_/REDIS_/ALIYUN_/SMS_,注释称「仍保留
JWT_SECRET / APP_KEYS …… 本地无副作用」—— 该结论不成立:本地进程持有
**生产签名密钥** ⇒ 本地 token 可冒充生产用户(反之亦然),两套环境的会话边界
实际被打通,属**安全属性**缺陷。
修法:新增 DEPLOY_ENV_LOCAL_SKIP_KEYS 精确跳过(⛔ 不用前缀以免误伤),本地改由
scripts/.creds.local.json 供值;Python 侧 scripts/_fixtures.py resolve_jwt_secret()
同步为「非生产优先本仓凭据文件」—— 否则脚本会用生产密钥签 token 交给本地后端
验签,必然 401(正是该函数注释里记录过的 23 项级联假红)。
行为等价性(生产逐字不变,已逐项实测):
· D6/D8:生产显式注入 APP_KEYS / DB_HOST ⇒ 取值路径不变
· D7:生产 resetTestData 本有 403 守卫、导入默认 testFlag=false ⇒ 原不可达
· D9:isProdEnv=true ⇒ 不跳过任何键 ⇒ 生产加载路径不变
验证:
· 配置层双环境断言:本地 jwt=8066e07d5683 / keys=e4cfe40ff3ea(≠ 生产
a05591750093 / ae0d155385c1);生产两值逐字不变;生产 testDefaultPassword=null
· 本地后端真实重启(仅给 DB_PORT=3307、**不给 DB_HOST**)⇒ 启动成功,
/api/health {"code":0,...,"db":"ok"};日志显示跳过 16 个键(含 JWT_SECRET/APP_KEYS)
· D9 判决点 d9_verify_split.py:本地密钥签 token ⇒ 200;生产密钥 ⇒ **401**
· 生产部署后 r106_prod_sentinel.js:pass=11 fail=0;/api/health 200
· 门禁:verify_no_secrets.py VERIFY_ALL_PASS(HIGH 0,判别力自证 17/17);
verify_script_health.py H1–H4 PASS
|
2026-10-12 11:06:01 +08:00 |
|
|
|
c101b15e2e
|
feat(admin): 新增小组激活状态清单接口 /api/admin/teams
- router:GET /api/admin/teams(adminAuth;固定路径段,与既有路由无通配冲突)
- controller:teams() 整体透传 group/activated/includeTest(防前端筛选静默失效)
- service:getTeams(),键 = 组别+队伍号;成员并集 aggregation.team_uid ∪ contestants.team_id;学校取 aggregation.organization_cn;激活 = 全组成员均已激活;附 summary 与 schoolConflict
- model/aggregation:补声明运行库既有列 organization_cn / group(此前模型漏声明 ⇒ 查询被当未知列)
线上验证:R86 已部署上线,公网 /api/admin/teams 返回 401(鉴权在位)
|
2026-10-09 09:33:05 +08:00 |
|
|
|
481de69e3d
|
fix(agg-key): 归集键串行修复 —— 考试/作品提交记录不得跨选手串行展示
现象(人工测试反馈,已取证):
测试账号 吴巍荪(cid=621, test_flag=1) 完成一次高职考试提交后,
正常生产账号 王乐乐(cid=600, test_flag=0) 在管理端评分列表出现**完全相同**的
作答数据(70 题 / 38 分),而王乐乐本人从未作答。
根因:
各提交表的 aggregation_uid 写入键不统一 ——
- 中职/高职:controller/exam.js 写 aggregation_uid = contestant.id
- 本科/教师:*_submissions 写 aggregation.aggregation_uid(真实聚合 uid)
历史实现为兼容「两种写法并存」,对两侧都做**无条件双键归集**
(同时用 contestant.id 与真实 aggregation_uid 去匹配提交表)。
而这两套编号来自**彼此独立的自增序列**、数值区间完全重叠 ⇒
「某人的真实聚合 uid == 同组另一人的 contestant.id」时,
前者会把后者的作答/作品记录「借」过来展示。
生产实测共 283 对碰撞(gaozhi 239 / benke 43 / jiaoshi 1)。
治法:新增唯一真相源 app/lib/aggregationKey.js
- 主键按组语义确定:考试组 = contestant.id;作品组 = 真实 aggregation_uid
- 兜底键沿用历史混杂写法,但**仅在与同组任何主键不冲突时**才启用
(未通过者丢弃 —— 只丢掉「本就会命中他人数据」的兜底,保留其余兼容性)
- 不设「兜底键被多人共用」分支:两套编号各自都是 PRIMARY KEY
(aggregation_uid / contestants.id),该情形结构上不可能发生,属死判据
- 6 处归集点全部改走该模块:
service/admin.js getExamSubmissions / getScores(考试分支) / getScores(作品分支)
getContestantScore / _reviewWorks
controller/score.js _resolveTeamScoreSource(考生端,与 getContestantScore 同函数)
生产实测影响面(用**线上实际部署的模块** + 生产真实数据核算,n=600):
旧规则碰撞对 283 → 新规则残留碰撞 **0**;兜底保留 317 / 丢弃 283
守恒校验:保留 317 + 丢弃 283 = 600;丢弃数 == 旧规则碰撞对 ⇒ YES
观测值会变化的考生 = **仅 1 人**(gaozhi cid=600 王乐乐 旧=70 → 新=0,即本病例)
吴巍荪 cid=621 归集键 ["621","642"] 行数 70 保持 **未被误伤**
验证:scripts/verify_agg_key_crosstalk.py 17/17 PASS(真实 HTTP + 库内真值)
夹具刻意构造「真实聚合 uid == 同组他人 contestant.id」并含**正向对照**(兜底保留者)
变异自证 A(拆掉碰撞闸门)→ H1/H4/H5/H6/B1/B4 共 6 项变红,失败信息精确复现原现象
变异自证 B(兜底键整体删除=过度修复)→ H3/H4/H5/H8 共 4 项变红
⇒ 两条职责各有独立判别器;还原后 diff 空、md5 一致、零标记残留
部署(生产 back-end):线上 3 文件 md5 与本地逐文件一致;
MainPID 3343212 → 3344477;8023 监听正常;journalctl -p err = -- No entries --;
路由探针 health 200 / 错口令 HTTP200+code4004 / 不存在路由 404 / 未授权 401
|
2026-10-08 12:23:18 +08:00 |
|
|
|
a471487092
|
fix(admin): 修复选手管理「激活状态」「注册日期」筛选被静默丢弃
现象(人工测试反馈):选手管理页「激活状态」下拉选择后列表无变化。
根因 —— 两层都在丢参且零报错:
- controller/admin.js 只解构 group/keyword/page/pageSize,
前端已发出的 activated 从未透传给 service
- service/admin.js 即使收到也未解构 activated,where 中根本没有该条件
- 同族缺陷:前端还发了 startDate/endDate(注册日期范围),
controller 同样未转发 => 该筛选同样失效(此前无人报告)
修复:
- controller:将 activated/startDate/endDate 整体透传给 service
- service:解构 activated,并对 BOOLEAN 列做白名单归一化
前端 el-select 传的是字符串 'true'/'false',直接入 where 会被
MySQL 隐式转为 0,导致「已激活」错查出「未激活」(比不筛选更难察觉);
白名单之外的值(含 undefined/'')一律视为未指定忽略,
避免畸形入参被当作 false 而静默缩窄结果集
验证(scripts/verify_accounts_filter.py,9/9 PASS,真实 HTTP + 独立 DB 真值):
A1 无筛选 total=26 == DB 26
A2 activated=true -> 10 == DB 已激活数
A3 activated=false -> 16
A4 分区性 10 + 16 == 26(关键判别器)
D1 日期限定 DB 实际存在那天 -> 20 == DB 当日
D2 负向对照(范围早于最早记录)-> 0
变异自证:拆掉 where.activated 分支重跑 -> A2/A2b/A3/A3b/A4 全红 EXIT=1,
失败信息精确复现原现象(total=26 != 10);还原后 diff 空、md5 一致、无标记残留
同族扫描:全后端 ctx.query 仅 11 处,逐点核对 => 仅 getAccounts 一对丢参
部署(生产 back-end):
线上 md5 与本地逐文件一致(controller ad0e60f8 / service 93eb3dbb)
MainPID 3341710 -> 3343212;8023 监听正常;err 级日志 -- No entries --
路由探针:health 200 / admin-login 错误口令 HTTP200+code4004 / 不存在路由 404 /
未授权 accounts 401
|
2026-10-08 11:22:18 +08:00 |
|
|
|
154338e5dd
|
feat(big-question): 综合大题 Excel 模板下载 + 批量导入(R73)
新增 GET /api/admin/big-questions/:group/template —— 生成自解释模板:
数据 sheet 排第 1(导入侧按 SheetNames[0] 解析,是承重契约)+「填写说明」sheet,
含列名含义/状态建议/常见被拒原因,让测试人员下载即会用,不依赖外部文档。
新增 POST /api/admin/big-questions/:group/import-excel —— 逐行调用
service.bigQuestion.createQuestion,标题长度/三小问/分值/泄题检测(detectAnswerLeak)
全部自动继承,与手工录入同一入口同一校验;批量导入绝不成为绕过防呆的后门。
组别以 URL :group 为准,忽略表格里的组别列;同组内标题重复即跳过并报错;
状态缺省 0(停用),批量录入的题未经人工校对不直接进抽题池。
客观题模板 buildQuestionTemplate 同步加「填写说明」sheet:数据 sheet 仍排第 1、
原 8 列不变,故 importQuestionsFromExcel 的 SheetNames[0] 解析不受影响(已离线验证)。
路由顺序硬约束:含具体段的 template / import-excel 必须排在通配段 /:id 之前。
|
2026-10-08 10:08:41 +08:00 |
|
|
|
d44d466a90
|
fix(exam): 考试组已交卷禁止再进入与重复提交(4006 门控)
|
2026-09-30 15:46:43 +08:00 |
|
|
|
a2e24aba2a
|
feat(auth): 口令强度策略(弱口令黑名单 / 账号派生值 / 长度上限)
背景(R61 实测):浏览器密码管理器在「设置密码」页预填 123456,考生若直接提交,该口令即成为其账号真实口令;而后端此前仅由 validate 校验「长度 >= 6」,弱口令完全合法。R62 已从前端修掉预填,本次补齐后端这道闸门。
- app/lib/passwordPolicy.js + password_blacklist.json:口令策略唯一事实来源。黑名单刻意做成纯 JSON,供 Node 运行时与运维脚本共用,避免两份清单漂移。
- controller/auth.js:activate() 与 resetPassword() 接入策略(错误码 2001 / 7001),位置在 validate 之后、短信校验之前(纯本地计算、无副作用、快速失败)。
- validate/index.js:补 max:20,与前端 el-form 规则对齐(此前只有前端限制长度上限)。
- scripts/_db.cjs:DB 配置解析唯一入口;scan_weak_password_accounts.cjs:存量弱口令只读扫描器;verify_password_policy_api.cjs:真接口验证(含「强口令通过」正向对照臂,防假绿)。
|
2026-09-30 11:56:35 +08:00 |
|
|
|
31da9580e5
|
fix(backend): 治理孤儿文件三根因(覆盖前删旧件 / 入库失败回滚 / 清库同步删件)(BACKLOG C9)
R45:C8 只清了存量(1003 个 / 9.62 GB),「孤儿为何持续产生」的三条根因仍在,本次一并治理。
顺序铁律「先库后盘」:文件删除不可回滚,若先删盘而 DB 写/事务失败 ⇒ DB 指向已删文件
⇒ 下载 404 = 数据丢失(比留一个孤儿严重)。故全部删除点一律「DB 侧确定成功 → 才删物理文件」。
- app/service/upload.js
· saveSubmissionRecord:覆盖前记住旧物理文件路径,existing.update() 成功之后才删旧件
(原先 upsert 只改 DB 指向 ⇒ 重传 N 次 = 1 条 DB + N-1 个孤儿)
· deleteSubmission:裸 fs.unlinkSync → 复用统一入口
· 新增 removePublicFile(relativePath, label):唯一删除入口。仅允许 works/ 或 tmp/ 前缀
(挡住脏 file_path 指向 templates/、carousel/ 等静态资源被连带删除)+ 拒含 `..`
+ best-effort 永不抛错,返回 removed|missing|skipped(复用 helper.safeCleanup)
- app/controller/upload.js
· upload() / mergeChunks():新增 savedFileInfo|mergedRelPath + recordPersisted 两个标志,
catch 里仅当「已落盘 && 未入库」才回滚删除 ⇒ 已入库还删会删掉正被 DB 引用的文件
- app/controller/admin.js
· resetTestData:事务内先只读收集六列路径(exam/work/zhongzhi/gaozhi/benke/jiaoshi),
tx.commit() 之后才删物理文件 + 去重 + 上报 orphanFileCandidates/orphanFilesRemoved
验证:verify-c9.mjs 24/24 · verify-c9-reset.mjs 12/12 · verify-c9-rollback.mjs 13/13
check_upload_import_gate.py 14 PASS/0 FAIL · 后端重启(node dev.js)后真实接口联调通过
配套:scripts/scan_orphan_files.py(兜底双向扫描,仓库级工具)
|
2026-09-29 15:06:53 +08:00 |
|
|
|
e8a5b34d42
|
fix(backend): 补齐单次上传端点的并发护栏(BACKLOG C7)
- middleware/concurrency_guard.js: HEAVY_PATTERNS 增加单段上传正则
/^\/api\/upload\/[^/]+$/i —— 单段锚定([^/]+$)保证不误伤"两段"的轻路由:
GET /status、GET /submissions、DELETE /:id(放宽成前缀匹配会让「查状态也 429」)
- controller/upload.js: upload() 补 await acquireFileIo() +
finally { if (ioAcquired) releaseFileIo(); }
⚠️ 不用 uploadChunk 的无条件 release:本方法 429 分支是 acquire 失败后 return,
无条件释放会把"别人的"配额放掉 => 计数下溢 => 护栏静默失效
背景:修复前该端点是**唯一在用**的作品上传路径(Competition.vue:477),却既不在
concurrencyGuard.HEAVY_PATTERNS(表内 chunk/merge 已成死路由)、也不调 file_io_guard
=> 零护栏。因服务器入带宽仅 ≈1.25MB/s 天然节流,当前风险有限,但按 C3 升入带宽
后即变实质风险 => 与 C3 绑定,先补护栏。
验证:
- verify-guard-r43.mjs 33/33(单元:路径判别力 + 满载 429 + 配额隔离 + 释放语义 + 变异自证)
- verify-guard-r43-live.mjs 8/9(真接口:30 路 5MB 并发上传 => 20 成功 / 10 个 429 +
Retry-After: 2;15 个轻路由探针在并发中全 200;唯一失败为清理步骤,根因是
saveSubmissionRecord 的 upsert 语义,非缺陷)
- 重启后 master PID 23684;[AppBoot][pool] 40 <= 151
|
2026-09-29 13:17:53 +08:00 |
|
|
|
0531131f0e
|
feat(admin): 报名表导入补列名别名 + 只导参赛选手 + 判重口径(R32)
- COLUMN_ALIAS/pick():兼容上游列名(身份证号码/全名/队伍ID),上游导出表免改表头
- 只导身份=参赛选手:其余计入 result.ignored/ignoredBy(≠skipped),建团队同步过滤
- 判重改以身份证号为准(同证即同人);错误消息附「队伍/姓名/手机号」便于同名定位
- 修 teamUidCache 复用库内团队时写入 maxTeamUid 而非真实 uid 的 bug
- phone 空值写 ''(列 NOT NULL)
- 实测:1225 行 -> 成功 591 / 跳过 3(身份证非18位)/ 忽略 631 / 建队 297
|
2026-09-29 09:40:51 +08:00 |
|
|
|
e74778ee08
|
feat(admin): 成绩导出改为 Excel + 板块迁移配套接口(R29)
- service/admin.js: 抽出 buildScoreExportTable(group) 作单一数据源(CSV/XLSX 共用,消除表头漂移)
+ 新增 exportToXlsx()(SheetJS aoa_to_sheet + write buffer + !cols 列宽)
- controller/admin.js: 新增 exportExcel()(xlsx MIME + ctx.attachment 中文文件名编码)
- router.js: 新增 GET /api/admin/export-excel/:group(adminAuth)
- export-csv 路由刻意保留:verify_full_e2e.py B10/D10、verify_upload_download.py B2 依赖其非空断言
|
2026-09-28 16:42:36 +08:00 |
|
|
|
2ab0991310
|
fix(admin): 复核页选择题选项渲染修复 + 阅卷导出 Word + 评分两位小数(R28)
针对测试人员反馈的四项:
1) 复核明细「选择题大量空白」:options 为 text 列存 JSON 字符串,原先被原样透传,
前端 v-for 对字符串逐字符迭代(op.key/op.text 皆 undefined)⇒ 每字符渲染一行。
新增 parseOptions()(仅 string 才 JSON.parse,失败降级 null)。
2) 选项与答案不随机:仅题目用 RAND() 抽题,normalizeQuestion 无 shuffle,字母无歧义。
3) 评分精度:DECIMAL(6,1) -> DECIMAL(6,2),migration 026 覆盖 17 列(与 025 同范围),
lib/decimal_score.js 与 11 个 model 注释同步;汇总收敛 round2(×100/100)。
4) 阅卷导出:GET /api/admin/big-answers/:group/export?ids=
单选考生 -> 直接 .docx;多位/全部 -> 每位考生单独 .docx 打包 .zip。
路由为 3 段,注册在 :group 通配段之前。
验证:verify_big_question 51 PASS/1 FAIL(唯一 FAIL=测试人员新数据,非本次改动)、
verify_score_leak_all_channels 24/24、verify_question_no_answer_leak 4/3/0/1。
|
2026-09-28 15:50:46 +08:00 |
|
|
|
cbc05ed4e7
|
feat(admin): 成绩复核——按姓名/身份证/电话检索考生并查看全卷客观题逐题作答与正确答案(R26)
- service.admin: 新增 reviewSearch / getContestantScore / _reviewWorks;移除同名的死代码旧实现
- 归集双键合并 [contestant.id] ∪ [真实 aggregation_uid],与 getExamSubmissions 口径逐字一致
- 题序还原:优先 exam_submissions.question_order,缺失则回退「选择→判断 + 题号升序」并回传 questionOrderFixed=false
- 未作答行 answerMatches 返回 null(非 false),避免界面把「未答」读成「答错」
- 组别以库中考生 group 为准,路由 :group 不符返回 409,防前端传错组照错人
- 异常可区分:questionMissing(题被删/改组)、answerMatches≠isCorrect(判分矛盾)
- 因回传正确答案,两条路由均挂 adminAuth —— 选手端可达即成绩泄露(与 verify_score_leak_all_channels.py 三通道门禁一致)
- 不改动 schema、不改动既有接口行为
controller.admin: 新增 reviewSearch / contestantScore(NOT_FOUND→404 / GROUP_MISMATCH→409 / 其它→400)
router.js: 注册 GET /api/admin/review/search 与 /api/admin/review/score/:group/:id,均 adminAuth
|
2026-09-28 10:15:42 +08:00 |
|
|
|
079c1b31c9
|
R20:客观题分值口径 + 大题一位小数评分 + 页面刷新修复 + 大题导出 Word
A1/A2 客观题:
- 清理题库占位题(答案恒 A/true、分值恒 5),客观题分值硬约束为 1 分
- 新增 scripts/check_question_bank_health.py(带变异注入自检,已验证判别力)
- ci-gates.sh 由 9 步扩为 10 步,纳入题库健康门禁
B 大题评分一位小数:
- 新增 app/lib/decimal_score.js:DECIMAL(6,1) + getter 兜底,单点收口
「DB 列 / model 声明 / dialectOptions.decimalNumbers」三处必须同时成立
- 10 个 model 的 score 字段改走该工厂
- database/migrations/025:17 列 INT → DECIMAL(6,1)(6 列题目分值保持 int)
- service/bigQuestion.js:setSubScores 用 Math.round(n*10)/10 收敛,不再抹成整数
C 页面状态刷新:
- 修复 onQuestionTypeChange 的 `bigQuestions.length === 0` 守卫(切组后旧数组仍非空
⇒ 永不重新拉取)
- 修复评分后只刷一半(saveBigScores / saveExamScore 各只刷一侧列表)
- 收敛为唯一刷新入口 refreshQuestionData();ensureBigData 改按「数据属于哪个组」
判定;fetchBigQuestions/fetchBigAnswers 增加组别竞态守卫
D 大题导出 Word(单题 / 批量 / 全部):
- 新增 app/lib/docx.js:零新依赖手写 OOXML(复用已有 archiver@8),支持 p/strong/
span/a/br/table/ul-ol 子集,具名捕获组词法解析,pPr 严格排在 runs 之前
- service.bigQuestion.exportQuestions + controller.exportBigQuestions +
GET /api/admin/big-questions/:group/export
- 前端导出选中/全部两按钮 + 表格多选(reserve-selection)
计划外发现并修复(已在报告中披露):
- 管理端跨组写分越权:setSubScores 定位作答行时缺 group 约束,可用任意组的路径
改写他组考生成绩(读写不对称:读取侧有 where:{group},写入侧没有)
⇒ 已补 group 约束,并区分「不属于本组」与「尚未抽题」两种文案
- 导出路由注册顺序:export 原注册在 :group/:id 之后(当时因后者仅 PUT/DELETE 而
未暴露问题),已前移以消除「将来新增 GET /:group/:id 会吞掉 export」的隐患
验证(全部实测,非仅看退出码):
- ci-gates.sh 10/10 全绿;四连门禁 52/0 · 22/0 · 20/0 · 46/0
- 端到端探针 probe_d_03(导出+小数)ALL PASS;probe_e_01(切组刷新)22/22 ALL PASS
- 前端构建 VITE_EXIT=0
未 push:须先上线验证通过再单独授权。
|
2026-09-23 18:29:50 +08:00 |
|
|
|
23604f2718
|
feat(exam/auth): 登录闸门 + 交卷稳定性加固(R4-R8)
R4 登录/交卷背压闸门
- app/middleware/concurrency_guard.js: 新增。超限即 429 + Retry-After(立即拒绝式,
不排队;实测 429 P50=34ms)。RETRY_AFTER 收敛为单一有依据常量 = '2'
(≈1.8 个满载窗口;实测 bcryptjs 1129ms / 原生 265ms 每窗口)。
配额:LOGIN_MAX=16 / SUBMIT_MAX=24 / HEAVY_REQ_MAX=20,各 *REQ_MAX 覆盖。
- config/config.default.js: 闸门配额与连接池容量配置;DB dialect 锁 mysql。
R7 顺序红线 + R8 Retry-After 同源 + 原生 bcrypt
- 3 处硬编码 '2' 收敛为单一常量;补"勿因换实现而删闸门"红线注释。
- bcryptjs -> bcrypt@6(N-API,Windows/Linux 均免编译;drop-in,存量哈希 $2b$10$ 兼容)。
- app/model/account.js / app/service/auth.js: 同步哈希实现注释(D4 全族 5 处陈旧
SHA256 注释修正)。
答题链路与综合大题
- app/controller/exam.js: 中职/高职综合大题接口(GET big-question / POST big-answer,
逐问 2000 字上限校验);uploadWord 对中职/高职封堵(400)。
- app/service/exam.js: 抽题快照 question_snapshot 落库、答案归集键修正。
- app/controller/auth.js / app/service/auth.js: toClientUser() 唯一出口,
未发布态按组剔除 score,exam_score/word_score/ppt_score 任何情况下不下发。
- app/router.js: 新增大题与管理端路由。
- app/extend/helper.js: 下载文件名 RFC5987 编码(禁双重编码)。
- app.js: 池容量断言按 env 区分单/多 worker(防 dev 假日志)。
验证:ci-gates.sh 9/9 全绿;verify_login_guard.py 28/28(含 D 组变异 9/9);
真实登录/抽题/交卷端到端 code=0;前端构建 BUILD_RC=0。
|
2026-09-22 09:16:55 +08:00 |
|
|
|
8ef18da395
|
feat(big-question): 中职/高职组「综合大题」在线作答 + 封堵 auth 成绩泄露三通道
## 一、需求变更:中职/高职组 Word 文件上传题 → 在线「综合大题」
按 2026-09-21 需求变更,中职组 / 高职组取消 Word 文件上传题,改为在线作答
综合大题(1 道大题 × 3 个小问 × 每小问 10 分 = 大题 30 分)。
- 新增表(迁移 023/024)
· `big_questions` —— 题库(题干富文本含表格 + 三小问提示语 + 评分口径)
· `big_question_answers` —— 作答(抽题快照 + 三小问答案 + 按小问得分)
两份迁移同时提供 `.sql`(生产直跑)与 `.js`(本地/CI 幂等执行)。
- 新增 model:`app/model/bigQuestion.js`、`app/model/bigQuestionAnswer.js`
- 新增 service:`app/service/bigQuestion.js`(抽题 / 保存答案 / 评分核心逻辑)
- 考生端接口(`app/controller/exam.js`)
· `GET /api/exam/:group/big-question` —— 首次抽题并落库题干快照,
后续一律返回同一道题(**幂等**,防止同一考生拿到不同题干引发纠纷)
· `POST /api/exam/:group/big-answer` —— 保存三小问答案,带考试窗口门控
- 管理端接口(`app/controller/admin.js`)
· 题库 CRUD:`/api/admin/big-questions/:group[/:id]`
· 作答查证:`GET /api/admin/big-answers/:group`(考生 → 抽到的题 → 三小问 → 提交时间)
· 按小问评分:`PUT /api/admin/big-answers/:group/:uid/scores`
- 服务端封堵越界数据:`app/controller/exam.js` 对中职/高职组的 Word 上传接口
一并拒绝(前端入口已移除,但直调 API 仍可绕过)。
**所有新增读写仅落在新增的两张表,不触碰任何既有表结构。**
## 二、安全修复(铁律 15 成绩泄露 —— auth 通道缺口)
原有成绩发布门控只覆盖 4 条通道,遗漏了 auth 的**三条同源通道**:三处都直接
回传 `toJSON()`,在 `score_published_<group> = false`(未发布)时照样下发成绩,
而同期 `GET /api/score` 正确返回 `null`。
- `POST /api/auth/login` —— 实测未发布态回传 `score`
- `GET /api/auth/current-user` —— 全字段 `toJSON`,连带下发分项
- `POST /api/auth/refresh` —— 全字段 `toJSON`,且前端 `doSilentRefresh()`
会把响应 `user` 写入 `localStorage` 与 Pinia,等效于登录通道;
实测泄漏 `score` + `exam_score` + `word_score` + `ppt_score` 共 4 个字段
修复方式:新增 `AuthService.toClientUser()` 作为**唯一出口**,三处全部收敛,
禁止各自直接 `toJSON`。口径:
- 该组已发布 → 保留 `score`;未发布 / 查询异常 → 剔除 `score`(异常按未发布,安全默认)
- `exam_score` / `word_score` / `ppt_score` **任何情况下都不下发**
(前端不使用;保留会形成"总分虽隐藏、分项可加总"的旁路)
门禁 `scripts/verify_score_leak_all_channels.py` 相应从 14 项扩到 20 项,
新增通道⑤/⑥/⑦断言(含"发布后 score 必须恢复"的**正向对照**,防止
"永不回传"式过度封堵造成假绿),并经变异注入自检证明断言可证伪。
## 三、移除已弃用的 Word 模板
中职 / 高职各 3 个历史 Word 模板(`app/public/templates/{zhongzhi,gaozhi}/*.docx`)
随需求一并移除;目录保留 `.gitkeep` 以维持路径存在。
---
验证:G10 铁律15 门禁 20/20 PASS(含变异自检,EXIT=0)、G9 铁律14 门禁 22/22 PASS、
窗口哨兵残留自检 6/6 PASS。前端配套改动见前端仓库提交 1bfe007。
|
2026-09-21 11:57:58 +08:00 |
|
WorkBuddy
|
a303cf2d53
|
chore: 后端首次基线提交
运行必须源码:app/(controller/model/service/middleware/lib/utils/validate/router)、config/、database/(migrations/seeders/sql)、启动脚本、app/public/templates 模板。
已忽略运行非必须:node_modules/、logs/、run/、app/public 运行时上传数据、.env*、构建/缓存产物。
|
2026-08-17 12:25:42 +08:00 |
|