LoveChengke
817af02357
功能级准入改为「权限键」，`requireRole` 退成默认模板。 权限组 - 权限目录（39 键：键 / 中文名 / 分类 / 默认角色）收口到 shared，路由挂 requirePermission / requireAnyPermission - 有效权限每请求实时算，改完分组立刻生效：ADMIN 全集且 permission:manage、system:manage 不可剥夺； CLASS_DEVICE 空集（不受分组影响）；有分组 = 并集（因此也能用来**收回**权限）；无分组 = 角色默认模板 - 新增「权限组」页：组增删改、成员分配、生效权限预览 - 班级维度的科目规则（assertCanManageSubjectContent）故意不可被权限组覆盖 客户端设备（ClassHelper 桌面端） - 设备身份是 deviceKey（首次启动生成的 UUID，saveConfig 拒绝改写、退出登录也保留） - 心跳走「DB 记状态 + 客户端定时拉」，不引入新的长连接：30 秒一次，在线窗口 90 秒 - 远控命令 shutdown / restart / logoff / lock：服务端有效期 10 分钟，客户端弹默认选中「取消」的对话框、 60 秒未确认按取消处理，执行后必须回执（重复回执幂等），同一台机器同一条命令只弹一次 - 新增「客户端设备」页：版本一览、一键推送更新、下发远控 客户端安装包由服务端下载并缓存（教室机常常没有外网，浏览器也受 CSP 限制） - POST /api/update/client/fetch 由服务端下载到 data/client-releases/<版本>/ 并登记 sha256 + size - 自动安装三条护栏：没有 sha256 就拒收、必须等到非上课且主窗口隐藏满 5 分钟、冒烟模式永不安装 大模型助手：只解析、不落库 - POST /api/ai/interpret 返回**待确认**的结构化动作（建作业 / 发通知 / 叫人）， 真正落库仍调既有端点 —— 权限断言、上课时段紧急通知保护、ClassIsland 推送全部自动复用 - 模型给的 params 用与手动入口**同一份** zod 再校验（模型输出不可信） - API Key 走 AES-256-GCM（密钥由 JWT_SECRET 经 scrypt 派生）加密存 AppSetting，只进不出 - provider=mock 是离线确定性解析，自动化验收一律用它；每次解析写一条 AiAudit（不含密钥） 系统与运维 - 开发者模式（服务端内存缓存开关，热路径不查库；开启后 500 才附 error.stack）、运行诊断（绝不回传密钥） - 开机自启动运行期可改：Windows 改 HKCU\...\Run、Linux systemctl enable/disable， **非安装形态一律返回 supported:false**，不往开发机的注册表里写自启项 - 服务端侧栏折叠只用 CSS 收拢（不重建 DOM），关怀模式只放大字号与控件、不动任何几何令牌 客户端 - 崩溃自愈：渲染进程挂掉 / 超 10 秒无响应先静默重建主窗口（10 分钟最多 3 次）， 未捕获异常只在「没在上课、没人看着」时才重启进程；冒烟模式绝不重启（会杀掉验证实例） - 上线补弹离线期间收到的消息只做一次：起点只在「可达 → 不可达」的边界写，恢复时取最近 5 条按时间升序推 发布内容批量 - POST /notifications/bulk、POST /homeworks/bulk：**单班失败不影响整批**，逐班返回结果 - 作业的科目名跨班**按名匹配**已有课程，找不到就整班记失败，绝不自动建课 （自动建课会把创建者写成任课老师，等于越权改任教关系） - 通知与作业同口径按「所属日期」归档，新增 /notifications/days 与 /notifications/creators BREAKING CHANGE: 能不能做某件事不再看角色名，而是看权限键（GET /api/permissions/me）。 未分组的账号按角色默认模板生效，行为与 1.2.0 一致；分组之后生效集合只由组的并集决定。 服务端首次启动会自动应用 1 个数据库迁移（权限组 3 表 / AppSetting / 客户端设备·命令·安装包 / AiAudit / Notification.assignDate / User.careMode，历史通知按本地日期回填），升级前请先备份。
6.8 KiB
6.8 KiB
title, description
| title | description |
|---|---|
| 更新与升级 | 检查更新与各形态的升级步骤、Linux 的升级回滚链路，以及升级前必须做的准备。 |
更新与升级
先知道版本是怎么回事
三端共用一套版本口径：
- 版本号的单一来源是仓库根
package.json。服务端在运行时读它（打包后读的是运行时清单）， 不在代码里写死； - 比较逻辑放在
@classhelper/shared的compareVersions/isNewerVersion，三端共用 —— 避免出现"客户端说有新版、服务端说没有"； - 数字相同、只有后缀不同时，带后缀的算更新（对应
v0.1.0-fix这种"同版本号的修复发布"）。
检查更新
| 端 | 入口 | 检查路径 |
|---|---|---|
| 服务端 / Web 管理端 | 顶栏用户菜单 →「检查更新」 | 浏览器 → 服务端 GET /api/update/check → GitHub |
| 桌面客户端 | 启动后自动一次（延迟 5 秒）+「设置 → 关于」里的「检查更新」按钮 | 主进程 → GitHub（不经后端） |
两端的路径不同是被约束逼出来的：
- Web 端不能直连 GitHub。服务端下发的 CSP 里
connect-src只放行'self'与 WebSocket， 浏览器发往api.github.com的请求会直接被拦掉。走服务端转发还有个好处：所有管理员共享同一份缓存 （GitHub 匿名限流是 60 次/小时/IP）。 - 客户端在主进程做。渲染进程的 CSP 与导航防线是安全模型里最要紧的一层， 不让它去连外部域名、解析外部 JSON。
"查不到"是设计内的结果
机房服务器与教室机器常常只有内网，请求会超时或失败。这时接口返回 ok: false + 一句人话
（「无法连接 GitHub，本机可能没有外网」），界面按"暂时查不到更新"呈现并给重试入口，
而不是弹红字报错。
失败结果同样进缓存 —— 否则断网时每点一次按钮都要白等一个超时。
| 细节 | 说明 |
|---|---|
| 缓存 | 两端各缓存 30 分钟；?force=1 绕过服务端缓存，但仅管理员生效（否则任意登录用户都能刷爆匿名限流） |
| 权限 | 任何已登录用户都能查（信息来自公开仓库）；force 除外 |
| 只提示一次 | 客户端启动检查发现新版才推提示；点「忽略此版本」记进配置，同一版本不再提示 |
更新只提示，不自动下载、不自动安装。安装包仍由人从 Releases
页面取，可用 SHA256SUMS-<版本>.txt 核对。
升级步骤
Windows 安装包
stop.cmd停止服务；- 备份
data目录； - 运行新版本安装程序 —— 覆盖安装会保留原有
.env，JWT 密钥与端口设置不变， 用户不需要重新登录； start.cmd启动。数据库结构如有变更，会在首次启动时自动补跑迁移。
如果升级后需要重新登录，说明 .env 被覆盖了（JWT 密钥变了），检查安装目录权限。
Linux
sudo classhelper upgrade --check # 只检查有没有新版本
sudo classhelper upgrade # 升到最新版
sudo classhelper upgrade --version 1.2.0 # 升到指定版本
sudo classhelper upgrade --url ./classhelper-server-linux-x64-1.0.1.tar.gz --sha256 <哈希> # 内网离线
sudo classhelper upgrade --url <包> --force # 强制重装同一版本
sudo classhelper rollback --list # 看有哪些程序快照
sudo classhelper rollback # 回滚到最近一份（会问一次确认）
upgrade 的完整链路（任一步失败都不改动程序文件）：
解析目标版本 → 下载 → 校验 sha256 → 备份数据与配置 → 快照当前程序文件 →
停服 → 替换程序文件（改名 + 就位，data/ 与配置原地不动）→ 起服 → 轮询 /healthz
↘ 失败：自动用刚才的快照回滚并重新起服，再告诉你失败原因
两点必须知道：
- 升级不会回滚数据库结构。如果新版执行过迁移，回滚程序前要确认旧版还能读新库，
必要时用
classhelper backup restore连数据一起回退。 - 替换程序文件用的是"改名 + 就位"而不是删除重写：升级时正在运行的就是
bin/classhelper自己， 必须先改名再放新文件，运行中的进程继续读旧 inode，否则 bash 会读到半个脚本。
Docker
docker compose pull
docker compose up -d
数据库迁移在启动时自动补跑。
手动 / 源码
拉新代码（或覆盖安装新的服务端程序）→ 重启服务端。启动时 db-bootstrap 会用账本表 _ch_migrations
对比已执行的迁移，只补跑缺的那些：
- 全新安装：依次执行全部迁移并创建初始管理员；
- 覆盖安装：只补跑账本里没有的迁移（已存在的表 / 索引自动跳过）；
- 已是最新：不做任何写操作。
日志里会明确写出「全新安装 / 升级安装」、应用了几个迁移、跳过了几个已存在对象。
客户端（ClassHelper 班级端）
从 Releases 取新的 setup.exe 覆盖安装即可，配置在 %APPDATA%，不受影响。
如果你是在自己维护的机器上只替换了
releases/里的产物、而没有同步到安装目录， 用户打开的还是旧的resources/app.asar—— 表现为"改了但界面不生效"。 覆盖升级时用robocopy ... /E推一遍，再对那个副本跑一次打包版冒烟确认。
ClassIsland 插件
必须先完全退出 ClassIsland（它会锁住 DLL），再覆盖插件，然后重启。
插件配置 Config\Plugins\<插件 id>\Settings.json 里存着服务器地址与设备令牌，别覆盖它。
升级前的准备清单
- 备份数据（
classhelper backup/ 复制data目录 /mysqldump）； - 记下当前版本号，必要时能回滚到它；
- 挑一个没课的时间 —— 升级期间实时推送会中断；
- 升级后确认
/readyz是 200，并且客户端顶栏的实时通道显示"已连接"。
给维护者
打版本、出安装包、发 Release 的完整流程见版本迭代与发布。