xuyue/OJ2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
279 Commits 1 Branch 0 Tags
8b4d8899f968a21de31d28dfcf6c992d1d6611a5
Commit Graph
5 Commits
Author SHA1 Message Date
xuyueandClaude Opus 5 ed56a209ea chore(格式): Prettier 统一到全仓，后端和契约一次性格式化
Deploy / deploy (push) Has been cancelled
Details 
原来只有 `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 2c4d56b29a refactor(后端): 清掉 Django 遗留的死列与手工级联，角色字符串收成一份 
三条迁移，一次部署（0008/0009 含 DROP COLUMN，需要 OJ2_ALLOW_DESTRUCTIVE=1）：

- 0008 删 IP 相关：比赛 IP 白名单（前端本来就没有输入框，detail.vue 无条件置空）、
  submission.ip（前端从未显示过）、以及一次都没被调用过的 IP 限流桶。
  judge_server.ip 是运维数据，保留。
- 0009 删九个只有 Django 时代写过、OJ2 一次都没读过的列：user 的 auth_token /
  open_api / open_api_appkey / session_keys，user_profile 的 blog / github /
  school / major / language。open_api 后台连开关都没有，那段「已经开着就不重置
  appkey」的逻辑从上线起没进过 if。判据是「全仓零读取」而不是「看着没用」——
  raw_password 同样刺眼却是在用的，别一起清掉。
- 0010 给 17 条外键补上删除动作，不再是 Django 留下的一律 NO ACTION。父行消失后
  必然无意义、且不构成学生留痕的走 CASCADE（中间表、题单/教程/成就的组成部分、
  user_profile 与 user_stat）；需要人看见的继续拦着——submission.problem_id、
  以及 user 的绝大多数外键，删用户撞外键会被 handler 翻译成「请改为禁用账号」，
  这是有意的：全 CASCADE 会静默抹掉成就与进度，而 submission.user_id 压根没有
  外键，结果是一半删一半留。六处手工级联随之删掉。

角色字符串收进 packages/contract/src/roles.ts：原先 ADMIN_ROLES / TEACHER_ROLES
在两个文件各抄一份、学生口径在四个文件各写一遍、前端 USER_TYPE 是第三份副本。
AuthUser.adminType 与 drizzle 的列都收窄成联合类型，二十多处 `=== "Super Admin"`
从此受编译器管着（$type 是纯 TS 层的，generate 确认不产生任何 SQL 变更）。

顺带删掉 db/relations.ts —— drizzle-kit pull 的产物，全仓零引用。

一处行为变化：后台用户列表传非法的 ?type= 回 400，不再静默返回空列表；界面上的
下拉只有合法值，打不到这条。

验证：tsc / vue-tsc / vite build / check:routes 全过；三条迁移在 dev 库执行，
并逐条建 fixture 走 HTTP 接口验过删除连坐与拦截（题单五张子表连坐、user_badge
二级连坐、删有提交的题目仍 409、删有表情的用户仍 409）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AeJoYc2t2d7cThVqMBYrBF
 2026-09-02 22:57:45 -06:00
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
xuyue ec274419c3 Build Phase 2 judge vertical slice 2026-08-06 22:42:39 -06:00