fix(admin): 审计筛选下沉 SQL + 工具数不再写死 + 模型删除加确认
清单里那批小毛病,逐条复核后修(「审计详情列缺失」那条已不成立,早补上了)。
1. 审计筛选只在当前页生效 —— 影响最大的一条。分页是服务端的,筛选却在
前端对已取回的 50 条做,于是搜一个用户 ID 显示"无结果"时,后面几页
可能还有几百条。审计的用途就是查证,"搜不到"会被读成"没发生过"。
改为 action/path/q 三个条件全部落到 SQL,前端只管发条件(防抖 300ms)。
2. 服务状态页把 mcp-go/mcp-py 的工具数写死成 23/4 —— 增删工具后一直骗人,
且服务离线时照样显示,看不出工具其实一个都没注册上。改取实际上报值。
3. 模型删除一点即删,无任何确认。补二次确认,并对"正在使用中"的模型
单独说明后果(删掉会立刻打断线上对话/向量能力)。
审计筛选补了 4 组回归测试,两条是踩出来的坑:
- q 的 OR 组必须带括号:gorm 以 AND 拼接各 Where,裸 OR 会让 action
条件被绕过(测试里用"同 IP 不同方法"两行钉死这个语义);
- LIKE 必须显式写 ESCAPE '\':Postgres 默认拿反斜杠当转义符,SQLite
不写就没有转义符——原来的写法在单测里静默失效,搜 "100%" 命中 0 条。
顺带把 ILIKE 换成 LOWER()+LIKE,这段才能被内存库覆盖。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -647,8 +647,20 @@ export interface GuardrailEventItem {
|
||||
at: string;
|
||||
}
|
||||
|
||||
export async function listAudit(limit = 50, offset = 0): Promise<AuditEntry[]> {
|
||||
const res = guard(await fetch(`${ADMIN}/audit?limit=${limit}&offset=${offset}`, { headers: authHeaders() }));
|
||||
// 筛选走服务端(全库匹配)。此前是取回一页再在前端过滤,翻页外的记录搜不到——
|
||||
// 对审计来说,“搜不到”会被当成“没发生过”,是会误导结论的。
|
||||
export interface AuditQuery {
|
||||
action?: string; // HTTP 方法,精确
|
||||
path?: string; // 路径前缀
|
||||
q?: string; // actor / ip / detail / path 模糊
|
||||
}
|
||||
|
||||
export async function listAudit(limit = 50, offset = 0, f: AuditQuery = {}): Promise<AuditEntry[]> {
|
||||
const p = new URLSearchParams({ limit: String(limit), offset: String(offset) });
|
||||
if (f.action) p.set("action", f.action);
|
||||
if (f.path) p.set("path", f.path);
|
||||
if (f.q?.trim()) p.set("q", f.q.trim());
|
||||
const res = guard(await fetch(`${ADMIN}/audit?${p}`, { headers: authHeaders() }));
|
||||
if (!res.ok) throw new Error(`audit failed: ${res.status}`);
|
||||
return ((await res.json()) as { logs?: AuditEntry[] }).logs ?? [];
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user