 tamakyi
|
d2aa0a1163
|
feat: v0.12.1 —— Worker 支持 UptimeRobot + 管理端远程访问 + 前后端分离
起因：核实「管理端在 Cloudflare 上是否有效」时发现一个更要紧的问题 ——
Worker 完全没有 UptimeRobot 同步能力（runChecks 的探测目标只有 config.monitors）。
而实际配置是 dataFilter=uptimerobot，也就是说直接部署到 Worker 面板会是空的：
它探测 8 个本地条目，而真正在监控的 6 个 UR 目标它根本不认识。
① Worker 支持 UptimeRobot（Step 1）
- edge/cloudflare/uptimerobot.js（新增）：Workers 版 UR 只读数据源，
与 prober/node/lib/uptimerobot.js 同一套语义（状态映射/ratios 解析/故障原因）
- runChecks 的探测集合扩展为「自建目标 + UR 镜像目标」；UR 目标只拉取不探测，
采用其状态并补齐本地 daily 分桶
- probeScope 与 dataFilter 解耦（与本地探针同语义）：config 范围不拉 UR，
uptimerobot 范围不探测本地
- 同步失败时标记 sources.uptimerobot.ok=false 并保留上次数据，
绝不把目标判为离线或从面板消失；UR 侧删除的监控自动清理
- 快照新增 probeScope；UR 目标带 meta（面板区分自建/外部）与 uptimeRatios
② 管理端远程访问（Step 2）
- settings.admin.allowRemote：探针默认只监听 127.0.0.1，显式打开才监听全网卡，
启动日志就此告警。这是 Cloudflare Tunnel 的安全前提（已实测两种行为）
- edge/cloudflare/tunnel.yml（新增）：命名隧道配置，只放行
^/(admin|api/admin/.*|assets/.*)$，其余 404 —— 不把公开面板一起挂到公网
③ 前后端分离（Step 3）
- Worker 侧 /admin 与 /api/admin/* 显式返回 403 + 指向文档的提示，
而非默默落到静态资源变成 404，确保边缘侧没有任何可写面
测试：新增 scripts/verify-worker.cjs（36 项）—— 把 Worker 以 data: URL 动态载入以
绕开 cloudflare:sockets，注入假 KV/静态资源/UptimeRobot 服务器，
不需要 wrangler 也不需要联网。全项目 8 套 310 项全部通过。
过程中抓到两个真 bug：
1. UR 同步失败的降级路径引用了不含 meta 的旧对象，导致 name/url 为 undefined、
UR 目标从面板上消失
2. stats.total 按 config.monitors.length 计数，在 probeScope=uptimerobot 时
与实际参与的目标数不符
另有一条测试夹具教训：内存版 KV 必须实现 get(key, 'json') 的类型参数
（真实 Workers KV 会自动反序列化），否则 state.monitors 恒为 undefined。
|
2026-10-14 14:51:28 +08:00 |
|
|
tamakyi
|
752fad412b
|
feat: v0.12.0 —— 表格每行绝对等高 + 管理 WebUI（2FA 绑定才能进入）
① 每行绝对等高
- 行高与内容长度彻底解耦：新增 --row-h: 72px 作为唯一基准
- 名称列改为「文本区限两行 + 徽标区固定单行」两段式；文本区用 .clamp2
- 关键点：必须用 height 而非 max-height —— 后者会让短内容缩成一行、
长内容撑到两行，反而产生 66px/71px 两种行高（实测踩过）
- 分组标题行用 :not(.group-row) 排除在数据行规则之外
- 事件表与监控表格共用同一个 --row-h，两张表视觉上也严格对齐
- 完整值仍可通过悬停 title 查看（已加断言强制所有截断单元格带 title）
- 卡片视图同样等高（13 视口 × 250px 全一致）
② 管理 WebUI + 2FA
- 新增 /admin 与 /api/admin/*；未绑定 2FA 时除绑定流程外一律 403
- 零依赖实现 TOTP（RFC 6238），用 RFC 4226/6238 官方测试向量验证（16 个向量）
- 内置 QR 码生成器（byte 模式 / ECC L / 版本 1-10，GF(256) RS 纠错 + 掩码评分），
用独立解码器实测：版本 1 与版本 6 均能读出逐字节一致的内容
- 绑定流程：口令 → 生成密钥（扫码/手输/otpauth 链接）→ 验证 6 位码 → 10 枚恢复码；
完成后凭本次验证码直接换取会话
- 安全：会话 id 32 字节随机数且服务端只存哈希；HttpOnly+SameSite=Strict；
30 分钟空闲/2 小时最长；同时间步的码防重放；恢复码一次性；
登录失败按 IP 指数退避锁定；不解析 X-Forwarded-For
- 管理功能：运行状态、探测范围、展示口径、维护窗口增删、立即重探、通知自检、
目标只读列表、最近事件
- 所有写操作只落 local.monitors.json（私有不入库），绝不改 public/monitors.json
过程中修掉三个真 bug：
1. 会话 cookie 的 Path=/admin 覆盖不到 /api/admin/*，登录 200 但后续全部 401
2. 恢复码登录被 verifyTotp 的 invalid-format 提前挡掉（恢复码非 6 位数字）
3. 超大请求体用 req.destroy() 硬断连接，客户端只看到 fetch failed 拿不到状态码
测试：新增 scripts/verify-admin.cjs（102 项），全项目共 7 套 274 项全部通过
|
2026-10-14 12:37:07 +08:00 |
|
|
tamakyi
|
bdaa31f10c
|
feat: P0 通知（邮件 + MeoW）与 TLS 证书监控，事件时间线与维护窗口
通知（P0-1）：
- 邮件：自写 SMTP 客户端，零依赖。465 隐式 TLS / 587·25 STARTTLS、
AUTH LOGIN+PLAIN、RFC2047 中文主题、base64 正文、多收件人；
服务器不支持 STARTTLS 时默认拒绝明文（需显式 allowInsecure）
- MeoW：按官方文档实现，昵称寻址、msgType/htmlHeight 走查询参数、
以响应体 status 判定成功（HTTP 恒 200）、429/404/403 可读化、
本地限流器遵守 3s/15min/60h
- 告警：连续 N 次失败去抖 + 恢复通知 + 同轮合并 + 去抖状态持久化
（data/notify-state.json，gitignore）+ 静默时段（跨零点）
- --test-notify 自检命令、--data-dir / SHIROKO_DATA_DIR
证书（P0-2）：
- 独立 TLS 握手取 notAfter（不动既有 fetch 探测路径），默认 6 小时一次
- 面板徽标 ≤14 天黄 / ≤7 天红，阈值 14/7/3 各告一次、已过期只报最严重一档
- 单个目标可用 tls: false 关闭
事件与维护（P1-1 的后端部分）：
- data/events.json 追加式事件流（最近 500 条）+ GET /api/events +
快照内附最近 20 条；redactDetails 时脱敏
- 维护窗口：窗口内不计入可用率、不发告警、显示「维护中」徽标
测试抓到并修复的三个真 bug：
1. SMTP 空闲超时无人处理 → 服务器不响应会把探针循环挂死
2. MeoW 限流器把空历史当 0 → 第一条通知永远被自己拦掉
3. 去抖状态在无事轮次不落盘 → 连续失败计数丢失、永远达不到阈值
验证：新增 verify-notify.cjs 39 项（假 SMTP / 假 MeoW / 三轮集成 / 维护窗口 /
真实证书握手），六套合计 154 项全通过。
|
2026-10-13 23:54:46 +08:00 |
|
|
tamakyi
|
3db3ce570a
|
chore: v0.6.0 baseline — 主题美化前存档
已实现：HTTP/TCP/Banner 探测、90 天可用率、表格/卡片视图、
数据源过滤、UptimeRobot 双向兼容、服务端驱动的刷新节奏、
刷新接口滥用防护与信息泄露控制。
|
2026-10-13 18:31:58 +08:00 |
|