 sun
|
621f9f847e
|
docs(m4): 收敛文档/dock/changelog,env 减到 4 个引导变量
M3 后所有业务配置(api_key/resource_id/speaker/format/sample_rate/...)已搬入
数据库,env 只剩 4 个启动引导参数(setup 前 / DB 还不存在时必需):
1. TTS_ADMIN_KEY 安装 token(/api/setup 鉴权)
2. TTS_DB_PATH DB 路径(可选)
3. PORT 监听端口(可选)
4. OPENAI_TTS_API_KEY OpenAI 端鉴权(可选)
之前 .env.example 仍列出 11 个 BYTEDANCE_TTS_* env,误导用户把配置填 env 里
(实际被 DB 覆盖,改了不生效)。
改:
- .env.example: 只列 4 个 bootstrap env,其他写"通过 WebUI 设置"
- docker-compose.yml: env 块只透传 4 个,加 named volume 持久化 tts.db
(无 volume = 容器重启丢所有配置)
- Dockerfile: 准备 /data 目录,appuser 可写
- CHANGELOG.md: 新文件,记 v0.2.0 全部 M0-M3 + 这次修复
不动:
- README.md(M4 第 5 步独立 commit,文件大)
- 集成测试(M4 第 6 步)
e2e 验证:
- go build ./... 通过
- 旧 .env 文件如果存在仍然兼容(env var 作为 DB 缺失时的 fallback)
未 push (待 M4 全部完成)
|
2026-08-30 23:23:53 +08:00 |
|
|
sun
|
272565f736
|
fix: VUL-003 完整修复,启发式/精确双模式 XFF 解析
VUL-003 (中): X-Forwarded-For 信任链可被伪造 IP 绕过限流
本服务定位为公网入口,即使单人使用,公网暴露意味着攻击面
与公开服务等同,不能"够用就行"。
采用渐进式披露设计,平衡易用性与功能性:
1. 启发式模式(默认, 不设环境变量 或 TRUSTED_PROXY_HOPS=0)
- 从 XFF 链尾扫描,跳过私有 IP,返回第一个公网 IP
- 适合 90% 部署(单跳/多跳/直出),无需了解精确跳数
- 限制:多跳 CDN 场景下,限流粒度为"按 CDN 边缘 IP"
- 直出部署:整个 XFF 分支不会执行
2. 精确模式(TRUSTED_PROXY_HOPS=N, N>0)
- 从 XFF 链尾倒数第 N+1 个位置取值
- 精准到真实 client,需按实际反代跳数正确配置
- N=1:单跳反代;N=2:CDN+反代;以此类推
3. 两种模式都从链尾扫描
- XFF 首值是客户端可控的,信任首值等于信任攻击者
- 链尾由受控的反代添加,天然免疫伪造绕过
4. 默认值从 1 改为 0(行为变化)
- 旧默认:精确模式 N=1,取 XFF 末值
- 新默认:启发式模式,跳过链尾私有 IP
- 对单跳场景行为相同
- 对多跳/链尾含私有 IP 场景新版更准确(返回真实公网 IP)
5. 配套
- middleware/ratelimit_test.go:24 个表驱动测试用例,
覆盖直出/单跳/多跳/伪造/畸形/精确 N 边界,全部通过
- setting/config.go:LogStartupSummary 显示当前 XFF 模式
- .env.example:重写说明,标注默认行为 + 何时需配
- README.md:新增"反代拓扑与 X-Forwarded-For 解析"章节
(何时需要/两种模式/行为对比/为什么从链尾/启动日志验证)
6. 已知边界:TRUSTED_PROXY_HOPS=00 等被 Atoi 解析为 0 的
输入归入启发式模式,日志不会出现"精确模式 0 跳"矛盾输出。
|
2026-08-26 00:36:22 +08:00 |
|