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
9 Commits
Author SHA1 Message Date
xuyueandClaude Opus 5 dd6a6a04eb refactor(密码): 删掉 PASSWORD_HASH_UPGRADE，无条件写 argon2
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
xuyueandClaude Opus 5 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
xuyueandClaude Opus 5 854895e162 docs(手册): 把密码哈希这道单向门写进回滚一节 
三处：

- 第一节「回滚保证（已实测）」加了更正框：那句「零差异」只成立在表结构层面。
  演练比对的是列，比不出「新站登录过的账号旧后端验不了」这种语义上的单向门。
- 第四节试跑注意事项加一条：PASSWORD_HASH_UPGRADE 必须关着。
- 第七节回滚加了前提说明，以及「万一已经改坏了」的修复步骤 ——
  查范围的 SQL，加上用旧后端的 manage.py shell 从 raw_password 重算 pbkdf2。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-16 09:59:12 -06:00
xuyueandClaude Opus 5 eadfa0b04a fix(部署脚本): 改成在服务器上直接跑，加 --check 
上一版是从本机 rsync + ssh 过去的，不是想要的形态。改成服务器上跑：
代码怎么上去（rsync / 以后的 git pull）不归它管，脚本只管起栈。

五道自检，前两道是这次在服务器上真撞到的失败：

  compose 版本 ≥ 2.20   depends_on.required 是那版才有的字段
  DATA_DIR              卷指向 OJ2/data → 中止（空数据，且不报错）
  DB_HOST               DATABASE_URL 还指着 oj-postgres → 中止
  JUDGE_STATE_DIR       没设的话新旧两个判题机共用运行目录
  旧栈还活着            oj-postgres / oj-redis 是新栈的上游

--check 只做只读校验，不建目录不动容器（mkdir 挪到起栈那一段了）。

## 跑出来的两个问题

1. 版本比较写反了。原来用 `sort -V -C` 判「这两行本来就有序」，结果本机
   compose 5.4.0 被判成「太老」。改成取 min(2.20, ver)，在 1.29.2 / 2.19.9 /
   2.20.0 / 2.24.5 / 5.4.0 / 0 六个值上逐个验过分界。
2. --check 里的 mkdir 会真的建目录，本机跑直接撞权限。挪走了。

自检全路径实跑过：旧栈没起时正确拦下；造两个同名容器冒充旧栈后全绿通过；
抹掉 DATA_DIR / DB_HOST 两条守卫都按预期中止并打出可操作的提示。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-16 09:34:39 -06:00
xuyueandClaude Opus 5 eb849ca5ab fix(镜像): apt 换清华源、去掉用不上的 ca-certificates；补部署脚本 
## apt-get update 在服务器上卡死

不是慢，是挂住不返回 —— 本机构建从来没事，所以演练没暴露。换清华源。两个细节：

- trixie 的源是 deb822 格式，在 `/etc/apt/sources.list.d/debian.sources`，
  老的 `sources.list` 在这个基底里是**空文件**，改它没有任何效果。
- **只能换主机名、必须保持 http。** https 源会在这一步失败，因为镜像里还没有根证书。

`ARG APT_MIRROR` 可覆盖。

## ca-certificates 是多余的

原注释写「给 AI 接口的 https 出站用」，不成立：Bun 和 Node 一样内嵌了一份根证书，
走自己那份，不读系统的 /etc/ssl/certs。

实测：把探针二进制丢进裸 debian:trixie-slim（没有 ca-certificates）请求
api.deepseek.com，握手正常、返回 401（没带 key），和装了的镜像行为一致。
去掉之后重新构建，clang-format / ruff 都在，https 出站照旧，487MB → 483MB。

哪天镜像里加了用 OpenSSL 做 TLS 的东西（curl、wget 之类），这条要重新考虑，
注释里写了。

## docker/deploy.sh

没有 git remote 时的部署路径：本机 rsync 推代码 → 服务器上构建 → 起栈 → 冒烟。
默认不推 docker/.env（两边不是一回事，覆盖掉是静默故障），要同步显式 --env。

起栈前两道守卫，就是今天在服务器上真撞到的那两种失败：DATA_DIR 没生效（卷指向
OJ2/data）、DB_HOST 没生效（DATABASE_URL 还指着试跑形态下并不存在的 oj-postgres）。
两道守卫都用当天那份坏 env 正反跑过：齐全时放行，抹掉这两个变量时都触发。
两半的语法也都 `bash -n` 过（远端那半是 heredoc，单独渲染后再查的）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-16 09:30:50 -06:00
xuyueandClaude Opus 5 1a059d0b88 feat(切换): 支持并行试跑，新站先挂 oj2.xuyue.cc 跑几天 
设计文档写的是「不双跑不灰度」，这次改主意了。理由：「只换前后端」形态下新栈
本来就不碰数据库进程，双跑的增量风险只剩「两个后端同时写同一个库」这一条；
换来的是**正式切换退化成改一行 NPM 上游**，比停机切换更稳，回滚也不用停任何容器。

## 两个新变量

    WEB_PORT          对外端口。8080 还被旧 backend 占着（机房是 81）
    JUDGE_STATE_DIR   判题机运行状态目录

JUDGE_STATE_DIR 是必须的：不设的话新旧两个 judger 会同时往
`data/judge_server/{run,log}` 里写。默认值用嵌套写法跟着 DATA_DIR 走
（`${JUDGE_STATE_DIR:-${DATA_DIR:-../data}/judge_server}`，compose 支持嵌套默认值，
试过），所以一次性切换那条路径完全不受影响。

test_case 和 public/upload 仍然共享 —— 那是故意的，测试点和题面图片两边必须
看到同一份。

## 手册

新增第四节「并行试跑」，后面章节顺移（原四~九 → 五~十），两处交叉引用一并改了。
第五节拆成两条路径：试跑过的只需改 NPM 上游 + 事后停旧栈；没试跑的走原来那套。
第七节回滚同理。

试跑那节写明了三件容易踩的：NPM 的 Websockets Support 必须打开（漏了的话页面
一切正常，唯独「判题中…」永远不动，而刷新一下结果就出来，自测很难发现）、
两边登录态不互通、以及双写的是真实数据不是沙盒（别在 oj2 上办正式比赛）。

## 验证

试跑形态 `config` 解析：判题机目录落到 judge_server_oj2、端口 8090、test_case
仍指向共享的那份；不设新变量时默认值一个没变（judge_server / 8080）。
四份 compose `config -q` 全通过。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-16 09:04:16 -06:00
xuyueandClaude Opus 5 cbff292551 feat(切换): compose 支持「只换前后端」，接着用旧栈的 postgres/redis 
演练把一件事盖住了：当时是把生产 dump 恢复进 `OJ2/data/postgres` 的，
所以没人发现新 compose 在 `OJ2/docker/` 下，`../data` 解析出来是 `OJ2/data`，
而旧栈用的是 `<部署目录>/data`（服务器上是 `/root/OJDeploy/data`）。

照原手册切过去，postgres 会在一个空目录上初始化一个全新的空库 —— 站点起得来，
但没有用户没有题、判题全挂、题面图片 404。旧数据完好，回滚正常，但当天会白吓一场。

## 改法

三组 env 旋钮，默认值保持原样，不影响本机和演练那条路：

    DATA_DIR    所有数据卷的根，默认 ../data
    DB_HOST/PORT      默认 oj-postgres:5432
    REDIS_HOST/PORT   默认 oj-redis:6379

postgres 和 redis 挪进 `profiles: ["local-data"]`，默认不起 —— 否则会跟旧栈
那两个抢 5445 / 5446。配套给 depends_on 加 `required: false`：实测严格的
depends_on 碰上未启用的 profile 会让整个 project 直接 invalid，不是可选项。
代价写进注释了：自带数据形态下 postgres 起不来时 compose 只警告不中止。

给 api / worker 加 host-gateway 映射，DB_HOST 填 host.docker.internal 就行，
不用去猜 docker0 的网段。数据库流量不出本机。

school 那套的 7 个挂载点同样换成 DATA_DIR —— 机房那台也有自己的旧数据目录，
测试点和题面图片都在里面，同一个坑。

## 验证

用 docs/specs/schema.sql 起了个发布在宿主机 5445 的 postgres 冒充旧栈：
正好 4 个容器（没有 postgres/redis）、oj-api healthy、首页与 /api/site
/api/problems 200、未登录进后台 401。读写两个方向都验了 —— 那个库的
pg_stat_activity 里有来自 172.17.0.1 的 postgres.js 连接，judge_server 表里
也出现了新判题机写进去的心跳行。

四份 compose 的 `config -q` 全通过。

手册第三、四、六节按这个形态重写：停旧栈改成只 stop oj-backend / oj-judge
（旧判题机会争 data/judge_server/run，旧 backend 占着 8080），回滚变成把这两个
再 start 起来，数据库进程全程不停。

**DATA_DIR 漏填不会报错**（它有默认值），是切换当天唯一会静默走歪的地方，
手册里给了 `config | grep source:` 的自查和两种症状的区分。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-16 08:57:25 -06:00
xuyueandClaude Opus 5 a47e051a49 docs(阶段5): 补验 WebSocket 经 Caddy 与机房那套 compose 
演练报告里原来有两块是没验过的，补上：

## WebSocket 经 Caddy

学生盯着「判题中…」变成结果就靠这条路，而它经过 Caddy 的 handle /ws/*，
是配置最容易写错、又只在生产才暴露的一段。实测 upgrade 成功，301ms 内
收到两条推送：judging → finished（AC）。

## 机房那套 compose.school.yml

和服务器那套差别不小（没有 postgres、连远程库、端口 81、COOKIE_SECURE=false），
之前一次都没跑过。留下 oj-postgres 当「远程库」、其余换成 school 栈跑了一遍：
连库、首页、题目列表、登录、WS、完整判题全通。

其中特意验了 **Cookie 没带 Secure** —— 带了的话机房（http 直连 IP）会出现
「登录成功但立刻又变未登录」，是那种看起来毫无头绪的故障。

顺带确认机房的拓扑是「本地 Redis + 本地判题沙箱 + 远程库」，
判题不跨公网，只有数据库查询走公网。

演练用的是 docs/specs/schema.sql 只灌结构，盘上不留学生数据；跑完已清干净。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-08 03:33:00 -06:00
xuyueandClaude Opus 5 fb22b7d49f docs(阶段5): 用生产快照跑完整切换演练 
演练用 compose.debian.yml **本身**在本机 Docker 里跑，不是简化版。
数据是 2026-08-07 的 pg_dumpall 快照：1710 用户 / 956 题 / 123140 提交。

## 出口标准达成

停旧栈 11s，起新栈 34s（镜像预先构建好），全链路验证约 2 分钟 ——
**停机不到 1 分钟**，远在 30 分钟内。真正的时间风险在构建镜像（首次约 5 分钟），
所以手册里第一条就是「镜像必须在停机窗口之前构建好」。

验证到位的：首页、站点配置、题目列表、标签、公告、登录（argon2 新哈希和
Django pbkdf2 旧哈希都支持）、个人页、排行榜、后台四个接口、判题机自动注册，
以及**完整判题**（提交 Python A+B → AC，1.2 秒，两个测试点全过）。

## 两件原以为要做、实测不用做的事

- **不需要任何 DDL**：生产 dump 和新后端在用的库逐列对比，两边都是 278 列，
  零差异。新后端直接跑在现有结构上。
- **不需要重置序列**：我在 phase3-coverage.md 里记的那条「切换必做：重置序列」
  **是错的**，来自我手工按显式 id 导入、又没补 setval 的本地库。真实的
  pg_dumpall 带 30 条 setval，且把快照里所有序列和 max(id) 逐个对过，错位 0 个。
  已在原文档上标注更正，没有删掉原文 —— 错误结论本身也是信息。

## 回滚保证已实测

新栈跑完登录、提交、判题之后，再和生产 dump 比一次结构：逐列一致，零差异。
加上数据目录布局照抄旧后端，回滚 = 停新栈 + 起旧栈，约 20 秒，不动任何数据。
（未实测的部分也写明了：本机没构建旧 Django 镜像，「起旧栈」这一步没跑过。）

## 演练抓到的真问题

**pg_dumpall 备份会覆盖数据库口令。** 恢复完快照，新后端立刻报
`password authentication failed` —— 因为 dump 里带
`ALTER ROLE onlinejudge ... PASSWORD 'md5…'`，把角色口令覆盖成了备份时生产的那个。
正常切换不受影响（根本不恢复备份），但灾难恢复时这一条不写下来，
现场会被一个看起来毫不相干的报错卡住。

**恢复备份前必须先停应用**，否则 dump 里的 DROP DATABASE 失败。演练时因为
目标库是空的，数据照样进去了 —— 那是运气，目标库有数据就是满屏主键冲突。

## 镜像体积没达标，写明了原因

api 镜像 487MB，设计文档写的是「数十 MB」。一半以上（269MB）是 clang-format
拖进来的 LLVM，光 libLLVM.so 就 124MB。旧 Python 镜像同样装了 clang-format，
所以新镜像仍明显更小，但当初估「数十 MB」时没把它算进去。
瘦身路径也记了（换静态 clang-format 可砍 265MB），暂不做。

## 清理

演练在 data/postgres 留下了一份完整的生产数据副本，含 1710 名学生的
raw_password 明文列，已删除。手册里留了提醒 —— 那不是测试数据。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-08 02:13:59 -06:00