xuyue/OJ2 - OJ2 - Gitea: Git with a cup of tea

xuyue/OJ2

Fork 0

Commit Graph

Author	SHA1	Message	Date
yuetsh	34ae9b032c	fix(后台): SQL 测试点脚本读不出来时不能静默留一片空白编辑器用浏览器把前后台走了一遍（这是第一次真的在界面上验证，之前全是脚本打 API）。唯一找到的真问题在 SQLTestcaseEditor： onMounted(async () => { try { ... } catch {} // ← 静默吞掉 }) 已有脚本读取失败时被 catch{} 吞掉，编辑器保持初始的 3 个空白项 —— 和「这题本来就没测试点」长得一模一样，教师完全看不出发生了什么。改成：新题和旧格式测试点（404 problem-not-found / 409 not-sql-test-case）仍然静默留空，那本来就是对的；其它失败挂一条 alert，并且把可操作的部分说全 —— 后端那句"测试点信息读取失败"只讲了现象，教师需要知道的是「下面是空模板、直接存不会生效」。保存本身是安全的，已实测：拿一道真实 SQL 题，在编辑器空白的状态下点提交， test_case_id、测试点数（3）、sql_config 全部未变 —— 后端读不到测试点信息会拒绝整个保存（400），不会把测试点清空。所以这条只是提示缺失，不是数据风险。 ## 走查过程中的一次自我更正中途我一度报告"保存返回 400 而界面没有任何错误提示"，那是错的：提示是正常显示的，我第一次等了 4 秒才检查，而 Naive UI 的提示 3 秒就自动消失了。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-08 05:19:23 -06:00
yuetsh	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
yuetsh	ae1fb329b5	feat(阶段1): 搬入 ojnext 为 apps/web，未改业务代码	2026-08-06 21:18:16 -06:00

Author

SHA1

Message

Date

yuetsh

34ae9b032c

fix(后台): SQL 测试点脚本读不出来时不能静默留一片空白编辑器

用浏览器把前后台走了一遍（这是第一次真的在界面上验证，之前全是脚本打 API）。
唯一找到的真问题在 SQLTestcaseEditor：

    onMounted(async () => {
      try { ... } catch {}     // ← 静默吞掉
    })

已有脚本读取失败时被 catch{} 吞掉，编辑器保持初始的 3 个空白项 ——
和「这题本来就没测试点」长得一模一样，教师完全看不出发生了什么。

改成：新题和旧格式测试点（404 problem-not-found / 409 not-sql-test-case）仍然
静默留空，那本来就是对的；其它失败挂一条 alert，并且把可操作的部分说全 ——
后端那句"测试点信息读取失败"只讲了现象，教师需要知道的是「下面是空模板、
直接存不会生效」。

保存本身是安全的，已实测：拿一道真实 SQL 题，在编辑器空白的状态下点提交，
test_case_id、测试点数（3）、sql_config 全部未变 —— 后端读不到测试点信息会
拒绝整个保存（400），不会把测试点清空。所以这条只是提示缺失，不是数据风险。

## 走查过程中的一次自我更正

中途我一度报告"保存返回 400 而界面没有任何错误提示"，那是错的：提示是正常
显示的，我第一次等了 4 秒才检查，而 Naive UI 的提示 3 秒就自动消失了。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-08 05:19:23 -06:00

yuetsh

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

yuetsh

ae1fb329b5

feat(阶段1): 搬入 ojnext 为 apps/web，未改业务代码

2026-08-06 21:18:16 -06:00

3 Commits