xuyue/OJ2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
104 Commits 1 Branch 0 Tags
a9332df6bdaa12e9461cfffd3a7aed28a1b58ea1
Commit Graph

11 Commits

Author SHA1 Message Date
yuetsh
dd6a6a04eb refactor(密码): 删掉 PASSWORD_HASH_UPGRADE，无条件写 argon2
Some checks failed
Deploy / deploy (push) Has been cancelled
Details 
上一个 commit 把五个写入点收进 hashPassword，顺手把开关默认值翻成了 true 并
留下 false 分支当退路。这个退路是假的，删掉。

**开关只能拦住将来，修不了已经发生的。** 等真到了要把旧站拉回来的那天，活跃
账号早就都被登录/重置密码升成 argon2 了，这时候设 `=false` 一个也救不回来。
正经退路是切换手册「万一已经改坏了」那节的脚本 —— 拿 `raw_password` 重算
Django 的 `make_password`，能修已经变成 argon2 的账号。留着一个永远轮不到它
上场的开关，只是给后来人多一件要读懂的东西。

删掉的：`config.passwordHashUpgrade`、`hashDjangoPbkdf2` 和它那套 Django 参数
（1200000 迭代 / 22 位 salt / RANDOM_STRING_CHARS）、两个 compose 里的
`PASSWORD_HASH_UPGRADE` env。auth.ts 的登录升级变成无条件。

保留的：

- `hashPassword()` —— 虽然现在只是一行 argon2，但「只有一个地方写密码」正是上
  一个 commit 的重点。五处各写各的才是当初那个 bug 的根。
- `verifyPassword` 的 **pbkdf2 分支** —— 生产库 1710 个账号全是 Django 写的
  pbkdf2（迭代次数 120000～1200000），只会在各自下次登录时才迁移。删了就是
  全站登不上。代码注释里写死了这句话。
- 切换手册里的 `raw_password` 恢复脚本，以及回滚流程里新加的「密码要额外处理」
  那一步。

## 验证

改完重跑了一遍关键路径（临时造一个 Django 生成的 120000 迭代老哈希）：

- 存量账号登录 200 → 哈希变成 argon2 → 再登 200 → 错密码 401
- 后台重置密码 → argon2 → 新密码能登录
- 注册 → argon2 → 能登录

tsc(apps/api) 0 error、check:routes 168 条无遮蔽、vue-tsc 0 error、build 通过、
两个 compose `config -q` 通过。测试用户已删干净。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-25 23:50:55 -06:00
yuetsh
694e147a21 fix(密码): 五个写入点统一走 hashPassword，默认切 argon2 
## 那道「单向门」其实一直开着

`PASSWORD_HASH_UPGRADE` 是并行试跑第一天撞出来的补丁：新后端把 Django 的
pbkdf2 升级成 argon2 之后，旧后端验不了，登录过新站的学生回滚就登不上
（phase5 切换手册里记着这件事）。当时的修法是给**登录时的自动升级**加个开关，
默认关闭。

但写密码的地方有五个，开关只管住了一个：

    POST /users                          注册
    PUT  /admin/users/:id                管理员改密码
    POST /admin/users                    批量导入用户
    POST /admin/users/:id/reset-password 重置密码      ← 老师天天在用
    登录成功后的自动升级                  ← 只有这一处受开关管

后面四处无条件 `Bun.password.hash(argon2id)`。也就是说开关关得好好的，
**老师给学生点一次「重置密码」，那个账号就回不去旧站了** —— 而「老师帮学生
查/改密码」正是这套系统的日常功能，`raw_password` 那一列存在的理由就是它。
所以那半年里「默认关闭 = 回滚安全」是个假象。

## 改法

五处统一走 `auth/password.ts` 的 `hashPassword()`，开关两个方向都变成真的：

- `true`：五处全写 argon2id，登录时把存量 pbkdf2 顺手升级掉。
- `false`：五处全写 Django 格式的 `pbkdf2_sha256$1200000$<22位salt>$<base64>`，
  登录时也不动存量哈希 —— 两边都验得了。

新加的 `hashDjangoPbkdf2` 逐项对齐 Django 6 的 `PBKDF2PasswordHasher`：
1200000 迭代、22 位 salt、`RANDOM_STRING_CHARS` 字符集、sha256/32 字节。

**默认值定成 `true`** —— 旧站今天下线了，没有回滚路径要照顾。要把旧站拉回来
就先设 `PASSWORD_HASH_UPGRADE=false`，切换手册三处说明都改了。

⚠️ `verifyPassword` 的 pbkdf2 分支**永远不能删**，代码和注释里都写了：生产库
1710 个账号全是 Django 写的 pbkdf2（迭代次数 120000～1200000，跨了好几个
Django 版本），它们只会在各自下次登录时才升级成 argon2。

## 顺带：dev seed 只有学生号

`seed:dev` 只建 `student`（普通用户），本机想测后台得手工往库里塞 email 和
user_profile —— 而缺 user_profile 的表现极其隐蔽：`/api/me` 返回
profile-not-found → 前端 getMyProfile 抛异常 → localStorage 的 authed 存不进去
→ **所有 /admin 路由被守卫静默弹回首页**，不报错。我在这上面卡了很久。

现在 seed 同时建学生和超管（`devadmin` / `devadmin123`），profile 和 email 一起
建好，并且写密码也走 hashPassword。另外加了一道防呆：DATABASE_URL 不是本机时
直接拒绝执行 —— 这个脚本会重置密码并把明文写进 raw_password，其中一个还是超管，
对着生产库跑一次就是把超管密码改掉。要绕过设 `OJ2_SEED_FORCE=true`。

## 验证

全程拿**旧后端那个真的 Django venv** 对打，不是照着文档推：

- 事实核对：Bun 写的 `$argon2id$…` 在 Django 里 `identify_hasher` 抛
  `Unknown password hashing algorithm ''`；换成 Django 格式 `argon2$argon2id$…`
  能识别，但 `verify()` 抛 `Couldn't load 'Argon2PasswordHasher' algorithm
  library: No module named 'argon2'`（旧后端确实没装 argon2-cffi）。
  原注释说的「格式对了也验不了」结论对，机制略有出入。
- 双向互验：OJ2 写的哈希 Django `check_password` 通过、错密码不通过；
  Django `make_password` 写的哈希 OJ2 `verifyPassword` 也认。
- 默认（argon2）：拿 Django 现造一个 120000 迭代的老哈希塞进库，登录 200 →
  哈希变成 argon2 → 再登一次仍 200。
- 退路（`=false`）：同一个老哈希登录 200 且**哈希不变**；走后台「重置密码」
  之后落库是 `pbkdf2_sha256$1200000$…`，**旧站的 Django 验这个新密码通过**。
- 一次 1200000 迭代约 107ms（写密码时的开销；验旧哈希的开销本来就在）。
- tsc(apps/api) 0 error、check:routes 168 条无遮蔽、vue-tsc 0 error、build 通过。

测试用户（pwtest1 / legacyuser）已删干净，本机库用新 seed 复位。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-25 23:47:02 -06:00
yuetsh
604857b25e fix(一言): 接回真数据集，之前线上返回的是三条硬编码 
/quotes/random 在阶段 3 基线里只铺了个桩（三条写死的句子），读盘逻辑没移植，
所以 oj2.xuyue.cc 上一直是假数据——和 DATA_DIR 无关，哪儿部署都一样。

数据本来就在服务器上、位置也已经对上：旧栈挂 ./data/backend:/data，Django 的
HITOKOTO_DIR 就是它下面的 hitokoto/；OJ2 的 api 挂的是同一个目录。所以
Dockerfile 里跟着 TEST_CASE_DIRECTORY 写死 /data/hitokoto 即可，不用搬文件。

按分类懒加载并常驻，但只留前端用得上的 hitokoto/from 两个字段：原样缓存
7160 条要 2.5MB，裁完 1.4MB，而 api 容器只有 512m。读不到数据集时回落到
内置三条，不影响启动（本机 dev 默认就走这条）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-16 10:20:00 -06:00
yuetsh
face92a5dc fix(登录): 默认不再把 Django 的 pbkdf2 升级成 argon2 —— 这是道单向门 
试跑第一天就出事了：在 oj2 上登录过的账号，回旧站 oj.xuyue.cc 登不上，WS 也连不上
（旧站的 Channels 认 session，没登录自然连不上，两个症状同一个根因）。

`routes/auth.ts` 原来在登录成功后把 pbkdf2 哈希重算成 argon2id 写回库。问题是：

- Bun 写出来的是 `$argon2id$v=19$…`，Django 存 argon2 是 `argon2$argon2id$v=19$…`
  （多一个算法标签、没有开头的 `$`）。Django 按 `$` 切第一段当算法名，拿到空串，认不出。
- 更彻底的一点：旧后端的 pyproject.toml 里**根本没有 argon2-cffi**，
  格式对了也验不了。

所以这不只是双跑的问题 —— 一次性切换后的回滚窗口内同样成立：学生登录过新站，
回滚之后就登不上了。演练时比对的是表结构「逐列一致」，比不出这种语义上的单向门。

改成 `config.passwordHashUpgrade` 控制，**默认关闭**，并在两份 compose 的
environment 里显式声明 `PASSWORD_HASH_UPGRADE`（原来根本没透传，想开也开不了）。
等确定不会再回滚了再打开。

## 验证（真库真容器，不是看代码）

schema.sql 起库 + 造一个 Django 格式的 pbkdf2 用户（密码已知），跑新栈实测：

- 默认形态：登录 200，库里的哈希**仍是** `pbkdf2_sha256$260000$…`，容器里
  PASSWORD_HASH_UPGRADE 为空
- 对照组 PASSWORD_HASH_UPGRADE=true：登录 200，哈希变成 `$argon2id$v=19$m=655…`
  —— 正是生产库现在的样子，锁死可复现

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-16 09:57:43 -06:00
yuetsh
ce21a2bb8f feat(阶段5): 让 bun build --compile 的产物真正自足 
编译产物拿到没有 node_modules 的目录里跑，原来是一路崩的 —— 而且**在仓库
目录里跑时全都正常**，因为它顺着 cwd 找到了 node_modules，假装没事。
这类问题只会在服务器上第一次启动时暴露。逐个堵掉：

- `import.meta.dir` 在二进制里恒为 `/$bunfs/root`，往上三级就是文件系统根：
  `data/test_case` 悄悄变成 `/data/test_case`，`.env` 去读 `/.env`。
  新增 runtime.ts 显式分叉：编译后按 cwd，开发时按仓库根（后者不能改，
  compose 挂给判题沙箱的是仓库根的 data/test_case）。

- sql.js / tree-sitter 的 wasm、jieba 的 .node 和 4.8MB 词典，
  原来都靠运行时 require.resolve / Bun.resolveSync / __dirname 去 node_modules 里找。
  全部改成 `with { type: "file" }` 内嵌成资源。jieba 尤其绕：它的 index.js
  运行时探测平台再 require 子包，dict.js 用 __dirname 读 dict.txt，两条都
  依赖磁盘布局，所以单独包了 vendor/jieba.ts 直接 require 内嵌的 .node。

- SQL 判题要 spawn 一个能被 SIGKILL 的子进程，原来 spawn 的是 child.ts 的路径，
  编译后那个文件不存在。改成二进制自己按 argv 分发：新增 main.ts 作为唯一入口，
  serve / worker / sql-child 三个子命令，镜像里只需要一份运行时。

## 顺带修掉一个能拖垮生产的坑

「spawn 自己」意味着只要 argv 分发这一环出问题（子命令改名没同步、compose 里
command 写错、拿别的入口编了二进制），「起自己」就变成「把整个程序再跑一遍」，
而那一遍又会 spawn 一个自己 —— 指数增长。

这不是假想：开发时用一个没有分发器的临时入口编了个二进制，一跑就递归 fork
105MB 的进程，几秒触发 global OOM，内核把开发机的终端杀了
（`selftest invoked oom-killer ... Killed process ... Alacritty`）。
同样的错误发生在服务器上就是判题机连同数据库一起拖死。

加了递归闸：父进程 spawn 时打 OJ2_SQL_CHILD 标记，带标记的进程一律拒绝再 spawn，
最多一层就停在一条明确的 SYSTEM_ERROR 上。

## 验证

产物拷进只有它自己一个文件的目录，2G 内存上限下跑，7 项全过：
jieba 分词（自定义词「循环结构」「死循环」命中）、tree-sitter Python3/C 各两条
（含一条**预期失败**的规则做对照，否则「语言没加载成功」和「规则通过」返回值
一模一样，分不出来）、SQL 判题 AC、SQL 只读防护仍拦住 PRAGMA。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 23:13:57 -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
bc54fbff98 feat(阶段4): 站点配置 / 判题机 / 孤儿用例 / 概览 / 图片上传 
GET/POST          admin/website
  GET               admin/judge-servers
  PUT               admin/judge-servers/:id
  DELETE            admin/judge-servers/:hostname
  GET/DELETE        admin/orphan-test-cases
  GET               admin/dashboard
  GET               admin/random-usernames
  POST              admin/upload-image

顺带补上配置广播：旧后端改配置会经 WebSocket 推给所有开着页面的人，改完立刻生效。
新后端只服务 /ws/submissions，前端的 ConfigWebSocket 还连着旧 Django Channels。
现在加了 /ws/config 通道（同一个 Bun.serve 只能挂一个 handler，用 socket data 上的
kind 区分），前端 ConfigWebSocket 改走 /ws2/config。

几处判断：

- **判活不能比字符串**。库里 timestamptz 形如 `2026-08-07 13:42:50+00`（空格分隔），
  toISOString() 是 `...T13:42:44.000Z`（T 分隔），字典序空格 < 'T'，同一天的心跳永远
  小于阈值 —— 所有判题机都会显示离线。实测确实复现（dashboard 说 1 台在线、列表却
  两台全 abnormal），已改为 Date.parse 后比较。
- 删指定的孤儿用例时**先确认它确实是孤儿**。旧后端不校验，一个手抖的 id 就能删掉在用
  题目的测试数据，而测试数据没有别处备份。
- 图片上传的文件名完全由服务端生成，不带用户提供的任何一段；另加 10MB 上限 ——
  旧后端靠 nginx 兜，但机房那台机器盘写满之后判题也会一起挂。
- 停用判题机后不再 process_pending_task()：任务在 BullMQ 里排着，worker 恢复自己接着
  消费，不存在旧自研分发器那种「没有新提交就一直 waiting」的问题。
- dashboard 不再下发 env.FORCE_HTTPS / STATIC_CDN_HOST，前端从未读过。

实测：学生 403；配置读写回读 + oj 侧 /site 同步生效 + 还原；判题机列表带 token、
状态判定正确（一台 normal 一台 abnormal，与 dashboard 计数一致）；删不存在 404；
删非孤儿用例 404；随机点名缺班级号 400。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 07:43:38 -06:00
yuetsh
f548aef9f0 fix(阶段3): 补齐 contestId 脱敏与仓库根 .env 加载 
两处是首轮六条修复的收尾，均由验证过程暴露：

1. contestId 未脱敏 —— 旧后端 SubmissionSafeModelSerializer 排除的是
   info/contest/ip 三个字段，首轮只处理了 info 与 ip。

2. 根 .env 读不到 —— Bun 只自动加载 cwd 下的 .env，而启动方式
   (bun run --filter '@oj2/api' dev) 会把 cwd 切到 apps/api/，
   于是 .env.example 教人写在仓库根的 JUDGE_SERVER_TOKEN 静默失效，
   后端降级成随机 token，判题全部卡在 PENDING。config 改为显式补读
   根 .env，且只填充未设置的键（真实环境变量与 cwd 下的 .env 优先）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 02:12:31 -06:00
yuetsh
b7adf2993d fix(阶段3): 去掉判题机 token 的弱默认值 
F5：token 校验实现本身是对的（用了 timingSafeEqual），问题是缺省值
"oj2-dev-token" 写死在仓库里 —— 写死在仓库里的 token 等于没有 token。

后端改为对齐旧后端 options/options.py:93 的 fail-safe：
env 缺失时生成随机值并在启动日志里告警，判题机连不上，但不会静默用弱默认值。
compose 改为 ${OJ2_JUDGE_TOKEN:?...}，未设置直接报错退出。

本地开发怎么设写在 docker/compose.dev.yml 顶部与 .env.example 里：
两个变量名不同（判题机镜像认 TOKEN，后端认 JUDGE_SERVER_TOKEN）但值必须相同。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 01:59:27 -06:00
yuetsh
8c00cdc947 feat(阶段3): oj 侧端点铺开（基线提交，未经评审） 
由外部 agent (Codex) 在本会话额度中断期间完成。原样提交作为基线，
后续修复单独成 commit，便于区分与回退。

覆盖 oj 侧 65 个端点，新增 9 组路由（account/achievement/ai/classroom/
content/contest/flowchart/problemset/site）与对应 Zod 契约。

已核验：tsc --noEmit 退出码 0；API 可启动；/api/problems 返回真实数据；
judge 与 flowchart worker 均 ready。
未核验：权限边界与数据泄露，评审进行中。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 01:25:36 -06:00
yuetsh
ec274419c3 Build Phase 2 judge vertical slice 2026-08-06 22:42:39 -06:00