cdd0be328a
Critical runtime bugs:
- terminal.html WebSSH完全不可用(URL前缀/JSON解析/Content-Type三处错误)
- servers.py路由遮蔽:/logs被/{id}拦截,3个前端页面同步日志查询失败
- scripts.html startExecPoll()→startExecPolling(),长任务快速执行崩溃
- agent.py {value!r!s:.50}格式串非法,agent发非数值时ValueError
- alerts.html d.daily.reduce()无null检查,API返回空数据时TypeError
Resource leak / stability:
- websocket.py僵尸连接未关闭TCP,文件描述符泄漏
- websocket.py _last_alert_time字典无限增长(加1小时过期清理)
- asyncssh_pool.py全忙时超过MAX_CONNECTIONS无限增长
- self_monitor.py Telegram告警无冷却,宕机时每30秒刷屏
- schedule_runner.py一次性调度执行超60秒会重复触发
- 限速脚本EXPIRE每次重置窗口可绕过(改用Lua原子脚本)
Security:
- JWT access token加token_version声明,改密码后旧token立失效(零宽限)
- INSTALL_MODE导入时常量→动态函数,安装后JWT认证不再残留禁用
- install.py /lock端点加管理员存在性验证,防止阻断安装
- ServerUpdate schema移除connectivity只读字段,防止伪造连接状态
Frontend fixes:
- doExec()缺r.ok检查、commands.html null检查
- _server_to_dict()补last_checked_at+ssh_key_public
- _field_match()逗号cron表达式修复
- alerts类型显示、SSH会话名称、搜索高亮定位
- 一次性/循环定时任务(run_mode+fire_at+自动禁用)
Dead code removed (400+ lines):
- SyncService batch_push/_push_single等5个方法(零调用者)
- 5个未使用schema(SyncCommands/SyncConfig/SyncSftp/FileDeploy/PaginatedResponse)
- 6个零调用service方法、3个无前端API端点
- 4个未使用import
Schema migrations:
- push_schedules: run_mode + fire_at列,cron_expr改NULL
- servers: 7个新列 + ssh_key_private/public VARCHAR(500)→TEXT
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
3.6 KiB
3.6 KiB
纵深防御校验
概述
当你修复了一个由无效数据引起的 bug 时,在一个地方加校验似乎就够了。但这个单点检查可能会被不同的代码路径、重构或 mock 绕过。
核心原则: 在数据经过的每一层都做校验。让这个 bug 在结构上不可能发生。
为什么需要多层校验
单层校验:"我们修了这个 bug" 多层校验:"我们让这个 bug 不可能再发生"
不同层级能捕获不同问题:
- 入口校验捕获大多数 bug
- 业务逻辑校验捕获边界情况
- 环境守卫防止特定上下文的危险操作
- 调试日志在其他层级失效时提供帮助
四个层级
第 1 层:入口校验
目的: 在 API 边界拒绝明显无效的输入
function createProject(name: string, workingDirectory: string) {
if (!workingDirectory || workingDirectory.trim() === '') {
throw new Error('workingDirectory cannot be empty');
}
if (!existsSync(workingDirectory)) {
throw new Error(`workingDirectory does not exist: ${workingDirectory}`);
}
if (!statSync(workingDirectory).isDirectory()) {
throw new Error(`workingDirectory is not a directory: ${workingDirectory}`);
}
// ... 继续处理
}
第 2 层:业务逻辑校验
目的: 确保数据对当前操作是合理的
function initializeWorkspace(projectDir: string, sessionId: string) {
if (!projectDir) {
throw new Error('projectDir required for workspace initialization');
}
// ... 继续处理
}
第 3 层:环境守卫
目的: 防止在特定环境中执行危险操作
async function gitInit(directory: string) {
// 在测试中,拒绝在临时目录之外执行 git init
if (process.env.NODE_ENV === 'test') {
const normalized = normalize(resolve(directory));
const tmpDir = normalize(resolve(tmpdir()));
if (!normalized.startsWith(tmpDir)) {
throw new Error(
`Refusing git init outside temp dir during tests: ${directory}`
);
}
}
// ... 继续处理
}
第 4 层:调试埋点
目的: 记录上下文信息以便事后分析
async function gitInit(directory: string) {
const stack = new Error().stack;
logger.debug('About to git init', {
directory,
cwd: process.cwd(),
stack,
});
// ... 继续处理
}
应用模式
当你发现一个 bug 时:
- 追踪数据流 —— 错误值从哪里产生的?在哪里被使用?
- 标注所有检查点 —— 列出数据经过的每一个节点
- 在每一层添加校验 —— 入口、业务逻辑、环境、调试
- 测试每一层 —— 尝试绕过第 1 层,验证第 2 层能否捕获
实际案例
Bug:空的 projectDir 导致 git init 在源代码目录执行
数据流:
- 测试准备 → 空字符串
Project.create(name, '')WorkspaceManager.createWorkspace('')git init在process.cwd()中执行
添加的四层防御:
- 第 1 层:
Project.create()校验非空/存在/可写 - 第 2 层:
WorkspaceManager校验 projectDir 非空 - 第 3 层:
WorktreeManager在测试中拒绝在 tmpdir 之外执行 git init - 第 4 层:git init 前记录堆栈跟踪
结果: 全部 1847 个测试通过,bug 不可能再复现
关键洞察
四个层级缺一不可。在测试过程中,每一层都捕获了其他层遗漏的 bug:
- 不同的代码路径绕过了入口校验
- mock 绕过了业务逻辑检查
- 不同平台的边界情况需要环境守卫
- 调试日志发现了结构性误用
不要止步于一个校验点。 在每一层都添加检查。