4 Commits

Include renames

Author	SHA1	Message	Date
xuyueandClaude Opus 5.5	5ae830a7f9	refactor: 一批名不副实的命名改掉（只动一端，不碰契约） ... 后端： - getUserByToken → authenticateToken：它会删会话、续 TTL、记在线，不是纯读 - todayStart → dayStart(instant)：本来就接受任意时刻，不只是「今天」 - objectValue → asRecord，删掉 4 份一模一样的私有拷贝和 `as toObject` 别名 - 报错文案 "does not exists" / "Already be a public problem" 改通顺 前端： - utils/types 里 Contest / User / Problem 三个别名删掉：Contest 原来指后台 比赛、契约里同名的却是学生侧。现在 Contest = 学生侧、AdminContest = 后台， 后台用户表单叫 AdminUserForm，题目详情直接用 ProblemDetail - SubmissionInfo → ContestSubmissionInfo，免得和 submission.info 撞名 - utoa / atou → compressToBase64 / decompressFromBase64（实际是 zlib + base64）， encode / decode → base64EncodeUtf8 / base64DecodeUtf8 - filterResult → toProblemRow、toProblemListItem → toAdminProblemRow， 行字段 submission / rate → submissionCount / acRate - 组件：Modal → AddFromLibraryModal、Form → EditorToolbar、 ContestEditor → BasicEditor（题单也在用它）、rank 的 Index → RankMedal、 Name → UserNameCell、Password → PasswordCell、ContestType → ContestAccessTag Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 16:08:21 +08:00
xuyueandClaude Opus 5.5	b105fe3cbd	fix(测试点): 解压前按条目头拦大小，防 zip bomb ... 原来 unzipSync 先把整包解进内存，再逐个查大小 —— 检查之前就已经解完了。 实测一个 300KB 的 zip（10 个 30MB 的全零文件）让进程 RSS 涨 455MB， 容器只有 512MB。 - 第一遍 unzipSync 的 filter 只读目录、恒返回 false，按条目头的 originalSize 累计，单个超 32MB / 总计超 128MB 就抛；第二遍才真解，而且只解 N.in / N.out / N.sql（N ≤ 500），压缩包里别的文件一律不解 - originalSize 可以造假，但 fflate 按它分配输出缓冲、不扩容（解多了只截断）， 所以按它限额就是按实际内存限额 实测：同一个 zip bomb 被拦下时 RSS 只涨 1MB；单文件 300MB 的包按单文件上限拦； 正常测试点照常落盘、CRLF 照常归一、带 ../ 的条目名照常被忽略。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 15:14:12 +08:00
xuyueandClaude Opus 5	ed56a209ea	chore(格式): Prettier 统一到全仓，后端和契约一次性格式化 ... 原来只有 `apps/web` 在 Prettier 下（配置在 `apps/web/.prettierrc.toml`、脚本在 web 的 package.json），后端和契约从来没格式化过 —— 手写在 100 列上下，`db/schema.ts` 还是 drizzle-kit pull 留下的 tab 缩进。两套口径分叉久了，跨端改一处就得记着「这边 什么风格」。 - 配置搬到根目录 `.prettierrc.toml`，内容不变（`semi=false`，其余全默认， printWidth 80 —— 和前端已有的格式一致，不另立一套宽度）； - 脚本统一成根目录 `bun run fmt`，覆盖 `apps/*/src`、`apps/web/tests` 和两个构建 配置；web 自己那份 `fmt` 和重复的 prettier 依赖删掉； - `.prettierignore` 挡掉两类不该碰的：drizzle-kit 生成的 `src/db/meta/` 结构快照 （它是 db:generate 的比对输入，只该由 drizzle-kit 写）、unplugin 每次 dev 都会 重写的 `auto-imports.d.ts` / `components.d.ts`； - 全量跑了一遍。纯格式，无行为改动：api typecheck / check:routes / check:ast、 前端 type-check 全过，起 api 打了接口确认正常。前端这 39 个文件的小改动是 prettier 版本漂移（类型断言的换行口径变了），不是新配置带来的。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-16 08:27:34 -06:00
xuyueandClaude Opus 5	cd5dd16f3b	feat(阶段4): 测试用例压缩包上传与下载 ... POST admin/test-cases GET admin/problems/:id/test-cases （返回 zip 二进制） 落盘格式必须与判题沙箱镜像的约定一致（沙箱直接读挂进去的目录），已用真判题验证： 上传 zip → 建题 → 提交 Python 解法 → 沙箱读到用例并判出 Accepted。 安全与健壮性上比旧后端多做的几件事： - **zip slip 从设计上进不来**：不遍历压缩包条目，只按精确文件名（`N.in`/`N.out`/`N.sql`） 取内容，条目名一律不参与路径拼接。实测带 `../../etc/passwd` 条目的包能正常处理， 且只取到 1.in/1.out。 - 单文件 32MB、解压后总量 128MB、测试点数 500 的上限，防 zip bomb 与写满磁盘 —— 旧后端一概没有，机房那台机器盘写满之后判题也会一起挂。 - 坏 zip 返回 400 而不是 500。 对齐旧后端的细节：CRLF→LF 归一；`stripped_output_md5` 按 Python `bytes.rstrip()` 的口径只剥尾部 ASCII 空白后再算（实测与 hashlib.md5 结果一致）；编号从 1 起连续、 遇缺口即停；SQL 包至少 2 个测试点（题目页会展示测试点 1 的期望结果，只有一个时 学生可以对照着硬编码 AC）；目录 0710、文件 0640。 ## 顺带修掉一个只在判题时才暴露的路径 bug config 里的相对路径（data/test_case、data/avatar、data/upload）原先按进程 cwd 解析， 而起服务的方式会把 cwd 切到 apps/api/，于是测试点落在 apps/api/data/ 下 —— 但 docker/compose.dev.yml 把**仓库根**的 data/test_case 挂进判题沙箱。两边不是同一个 目录，新传的测试点判题时会「找不到测试数据」，且只在真正判题时才暴露。 改成一律按仓库根解析，实测沙箱能看到新传的目录。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 16:42:54 -06:00