laoyang/FeedLite
1
0
Fork 0
Code Issues 5 Pull Requests Actions Packages Projects Releases Wiki Activity
31 Commits 1 Branch 0 Tags
669ab9e43e25b44604d8478ace41f9253bc67207
Commit Graph
31 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
laoyang 669ab9e43e 修复图标显示不出来；标题改XX反馈系统；图标去掉背景色 
一、图标显示不出来（根因）
用户上传图标时用的是修复前的代码，数据库里 icon_key 存的是
icons/2026/11/xxx.png —— 没有 local/ 也没有 oss.prefix 前缀。
上一轮我把键校验收紧成「必须带存储前缀」，于是这些键被判非法，
fb_icon_url() 返回空字符串，图标自然显示不出来。
而三个文件其实都真实存在于 OSS 上（13KB / 391KB / 379KB）。

修法两层：
1. fb_icon_key_ok / fb_icon_is_key 兼容历史无前缀形态，
   这些是有效资产，不能因为键格式不规范就让图标消失
2. 数据迁移：把对象复制到 feedlite/icons/… 并把数据库键改成规范形态，
   已对三个软件全部执行并验证（新键 200，大小与源文件一致）

二、标题改为「XX 反馈系统」
- 页头大标题 = 同步日历反馈系统（之前只有「同步日历」）
- 浏览器标签同步改
- 软件名本身含「反馈」时不叠加，避免「轻反馈反馈系统」

三、图标不要背景色
- 去掉色块底衬与圆角投影，直接「图标 + 文字」并排
- 前端 badge、提交页上下文条、邮件头部三处同步
- md 尺寸调到 28px，与 26px 标题文字视觉匹配

验证：三个软件页标题正确、图标全部 200 image/png、
全部页面 200、迁移后新键可读且大小一致。
 2026-11-03 08:27:03 +08:00
laoyang 872baf4153 修复：图标存储未跟随后台配置，本地模式下图标显示不出来 
用户指出图标应当与附件同一套逻辑：管理员在后台配 local 就存本机、
配 oss 就存 OSS，前台都一样走 media.php 代理。

原实现把图标键硬编码成 icons/…（不带存储前缀），导致：
- fb_attach_is_local() 恒为 false
- 本机模式下文件确实写进了 uploads/icons/，
  但 media.php 把它当 OSS 对象去读 → 503，图标完全显示不出来

修法：图标键与附件完全同规则，只是路径里多一段 icons/
  local 模式 → local/icons/YYYY/MM/<hex>.<ext>  落 uploads/icons/
  oss   模式 → <oss.prefix>/icons/YYYY/MM/<hex>.<ext> 落私有桶
前台地址两种模式一致（media.php?k=…），换存储方式旧图标不会失效。

同时：
- fb_icon_is_key/ok 改为同时识别两种前缀
- fb_icon_allowed_ext 移到 attach.php（media.php 与校验都会用，
  不能依赖 admin_taxonomy.php 被加载）
- 写入时加断言：键前缀必须与当前存储模式一致，脱钩就报错，
  不再静默存到错误位置

验证（线上真实环境，两种模式各跑一遍）：
- local：键带 local/icons/ 前缀、写入 uploads/icons/ 成功、
  media.php 读回 200 image/png 501B、PNG 魔数正确、删除后 404
- oss：键带 fb/icons/ 前缀、is_local=false、URL 拼接正确
- 旧 bug 形态（icons/… 无前缀）现在被明确拒绝 400，不再误判成 OSS
- 测试后配置已复原为 oss，临时文件与诊断入口全部清理
 2026-11-03 08:19:17 +08:00
laoyang 835c8c05da 软件图标支持上传图片：存 OSS/本机，media.php 代理读取 
用户要求图标可以自己上传一张真实图片，而不是只能填一个字符。

设计：字符和图片并存，图片优先
- software 加 icon_key（图片对象键），icon（字符）保留作兜底
- 有图片用图片，删掉图片自动退回字符，任何时刻都不会没有图标
- 前端 badge 与邮件头部同一套判断，页面和邮件永远一致

存储与读取
- 图标走独立键空间 icons/YYYY/MM/<16hex>.<ext>
  不复用附件那套：附件必须挂在 thread 下才给读，图标不属于任何帖子
- 写：仅管理员（后台动作链）+ finfo 真实类型校验 + 尺寸下限 + 2MB 上限
- 读：media.php 对 icons/ 只校验键形状与文件存在（图标本就公开），
  写入侧仍然严格，不会让本站变成能读整个桶的开放代理
- 优先用 media.php?k= 代理；OSS 下顺便借图片处理缩放，省下行

顺手修掉两个真实安全问题
1. fb_icon_key_ok 原来用 [a-z0-9]{2,5} 匹配扩展名，.php 正好能过
   （3 个字母）—— 测试反向验证时发现，已改为图片扩展名白名单
2. fb_upload_key_ok 有同样的问题，附件键也能构造出 .php
   虽然真上传还有 finfo 兜底，但键本身就不该长这样，一并收紧
3. fb_icon_delete 原来用 @ 吞掉错误，删除失败仍返回「已保存」，
   用户会以为旧图清了、实际留了个可访问的孤儿图。改为返回 bool 并如实提示

验证：键校验 7 类非法输入全拒；图标写入 OSS 成功、media.php 读回 200 image/png、
PNG 魔数正确、缩放生效；越权读取（穿越/.php/未入库附件/不存在）全部按预期拒绝；
表单 enctype/文件框/accept/预览渲染齐全；仿真 PHP 伪图与 SVG 均被拒；
16x16 小图被拒。
 2026-11-03 08:13:21 +08:00
laoyang 738c6c09ff 多软件区分：邮件按软件换色+图标+软件名；补提交回执邮件 
用户要求：多软件并存时，用「颜色 + 图标 + 名字」三重区分，
邮件也要跟着所属软件变，一眼能看出是哪款软件的来信。

1. software 表加 icon / download_url 字段（幂等迁移）
   - icon 存单个字符（emoji / 汉字 / 字母），不存图片路径：
     前端与邮件用同一个字符渲染，天然一致，不用再管一套上传与权限
   - 没配 icon 时取名首字兜底，任何地方都不出现空图标
   - 后台软件编辑加图标快选（12 个常用 emoji）

2. 邮件配色改为跟随软件（fb_mail_brand 取 fb_software_colors）
   - 头部色条、按钮、引用块色条、徽标全部跟着软件走
   - 邮件头部改为「图标色块 + 软件名」，下面再小字标站点名
   - 主题行统一加【软件名】前缀，不点开就能分辨

3. 新增 receipt 事件：提交后立即给提问人发「已收到、待审核、请耐心等待」
   - 独立开关 notify.receipt_enabled（与「回复通知」是两件事）
   - 新增 7 处调用前的静默 return 也一并写日志

4. reply 邮件补上下文：原提问摘要 + 本次回复，像博客评论通知
5. status=resolved 文案改为「已完成并上线」，配了下载地址时给下载按钮

验证：多软件配色/图标/前缀全部通过（含反向验证），XSS 转义通过，
空图标兜底通过；页面顶栏、页头、选择器图标渲染正确。
 2026-11-03 08:00:50 +08:00
laoyang e43f2ce67a 修复：邮件通知两处静默失效（测试暴露） 
症状：notify_log 全表为空 → 用户报「完全没发邮件」，后台查不到任何线索。

1. 前 4 个前置判断（开关/收件人/自己回自己/冷却）直接 return 不写日志，
   等于「为什么没发」完全无痕。改为任何退出路径都写 notify_log，
   并带上可读原因。

2. new 事件（新反馈通知管理员）收件人只取 admin_email，该值为空时整条
   通知静默失效 —— 管理员永远收不到新反馈信，界面也无任何提示。
   改为回落 smtp.user / smtp.from；后台勾了「通知管理员」却没填邮箱时
   当场显示警告。

验证：走 fb_notify_event 全事件测试，6 个事件全部写日志、new 能送达。
 2026-11-03 07:31:35 +08:00
laoyang 8a850ca0e5 修复：全站图片 503 —— oss.enabled 派生写入被 has() 守卫拦掉 
问题：attachment.storage 存成 oss，但 oss.enabled 一直停在 0。
media.php 判 fb_oss_enabled() 为 false，直接 503「对象存储未配置」，
所有 OSS 附件（历史 + 新增）全部打不开。

根因有两层：
1. oss.enabled 是派生字段，表单里没有对应 input，上一个提交加的
   $save() 统一守卫用 $has() 判断「没提交」就 return，把它挡掉了；
2. 更根本的是两份状态描述同一件事 —— storage 和 enabled 迟早漂移。

修法：
- 派生写入改用 $saveForce()，并整段包进 if ($has(attachment.storage))，
  避免反向问题（没提交存储方式时被默认值改成 off）；
- fb_oss_enabled() 改为只看 attachment.storage 作单一事实来源，
  oss.enabled 仅在 storage 完全没配过的老库上作为回落。
 2026-11-03 07:21:04 +08:00
laoyang a850d479f0 安全：修复上传接口三个真实漏洞（可执行文件落盘 / 限流可绕过 / 真上传无限流） (#5) 
## 用户提问

「上传视频和图片的接口，有没有限制？会不会所有人通过 POST 都能随意上传？」

## 结论：防护大多到位，但存在三个真实漏洞

已核实有效的：CSRF、扩展名白名单、MIME 白名单、filesize 实测大小、
is_uploaded_file、类型开关、总量上限、uploads 目录 .htaccess 禁直连禁执行、
附件只走 media.php 代理。

但以下三个是真问题：

### 1. 🔴 可执行文件能写进 uploads/（最严重）

MIME 只校验**前端上报的字符串**，从不检测文件真实内容。

实测：把 `<?php system($_GET[c]); ?>` 改名成 .png、POST 里写
`mime=image/png`，一路通过所有检查写入磁盘。已确认真实文件内容：

    00000000: 3c3f 7068 7020 7379 7374 656d 2824 5f47  <?php system($_G

虽然 uploads/.htaccess 禁了脚本执行，但那是**唯一一道防线** ——
换 nginx、改配置、目录迁移，任何一步疏忽就是 RCE。

修法：新增 fb_upload_detect_mime()，用 finfo 读文件头魔数
（getimagesize 兜底），在 **move_uploaded_file 之前**校验真实类型。
不合格返回 415 并拒绝落盘。

### 2. 🔴 伪造 X-Forwarded-For 可无限绕过所有限流

fb_client_ip() 无条件信任 CF-Connecting-IP / X-Forwarded-For / X-Real-IP，
而这些头客户端随便写。

实测（upload_per_hour=2，连发 6 次、每次换个 XFF）：

    200,200,200,200,200,200   ← 上限 2 却全放行

影响面不止上传：fb_ip_hash() 用同一个函数，所以发帖限流、验证码频率、
所有基于 IP 的限制全部失效。

修法：默认只用 REMOTE_ADDR（客户端改不了）。新增 trusted_proxies 配置，
只有请求确实来自受信任代理/CDN 时才解析转发头，且只取**最右一跳**
（最左边是用户自己塞的，取最左等于把伪造的当前者）。

### 3. 真上传（action=put）没有限流

fb_rate_hit(upload) 只在领凭证时记一次，真正写盘那一段完全没有
fb_rate_check。拿到一个凭证后可反复 POST 覆盖写入。

修法：真上传独立限流 upload_put（与领凭证分开计数，避免互相挤占），
落地成功后才 fb_rate_hit。

## 验证：fb_upload_security.py，19 项

正常代码 **19/19**，覆盖：
- 无 CSRF 被拒 / 正常访客能传
- 限流生效（上限 3 连发 10 次 → 429 x8）
- 三种转发头都无法绕过
- PHP 伪装落地被拒（415，检测到 text/x-php）+ 未落盘
- .php/.phtml/.svg 全拒
- 存储关闭被拒
- 谎报 size 后落地仍用 filesize 拦住 + 未落盘
- uploads 防护文件完备（Require all denied / -Indexes / 禁脚本扩展）
- media.php 代理正常

## 反向验证（关键）

把三处修复全部回退后重跑，出现 4 项 FAIL：

    OPEN  改 XFF 不能绕过限流      上限2/6次: 200,200,200,200,200,200 放行 6
    OPEN  三种转发头都无法绕过      放行 9
    OPEN  伪装内容落地被拒         put 200
    OPEN  伪装内容没有落盘         磁盘=True      ← PHP 代码真的写进去了

证明测试确实能抓到，不是假通过。

## 测试踩的坑（写进注释）

- 领凭证必须带 ext/size/mime，缺了会返回「不支持的文件格式」，
  容易误判成「格式校验生效了」
- key 是 local/2026/11/x.png，实际落盘在 uploads/2026/11/x.png，
  直接拿 key 拼 FB_ROOT 判断「是否落盘」永远为 false → 假通过
- php -S 内置服务器不读 .htaccess，不能用 HTTP 状态验目录防护，
  改为检查防护文件内容（线上 Apache 实测 /uploads/ → 403）

## 回归

全新安装 33/33、邮件专项 73/73、配置守护 6/6。
 2026-11-03 06:56:11 +08:00
laoyang 605640aa90 根治：配置被跨页面保存清空（第三次复发，改为强制守卫） (#2) 
## 用户的原话

「为什么我的配置，你总是改掉？到底在干什么？我配的 OSS，好几次都让你给清空了。」

## 先给结论：没有重置数据库

installed_at 仍是 11-01 15:14，oss.* / site_name / admin.username 全都在。
但 **OSS 配置确实又被清空了**，而且这是我的问题，第三次。

## 时间线（这次是旧代码干的）

  22:53:36  用户点「保存设置」→ 日志记录：存储=off
  22:57:10  我的修复才部署上线

晚了 3 分 34 秒。所以那次仍是旧代码。
但这不能当借口 —— 同一类 bug 已经复发三次：

  11-01 23:20  storage=off
  11-02 09:01  之后被清
  11-02 22:53  storage=off

## 为什么反复修不好：一直在治标

前两次我的做法是「给用户点出来的那个字段补 has() 判断」。
但保存函数里有 **32 处 fb_set_setting，只有 8 处手写了 has()**。
漏掉任何一处，就是一次事故。这是结构性缺陷，不是个别疏忽。

## 这次的做法：从写入入口上锁

新增 $save() 强制守卫，**本文件唯一允许写设置的入口**：

    $save = function ($k, $v) use ($has) {
        if (!$has($k)) { return false; }   // 铁律：没提交就不动
        return fb_set_setting($k, $v);
    };

把保存函数体里全部 32 处写入统一改为 $save()。
现在除了守卫自身内部，**没有任何地方能绕过「字段没提交就不写」**。

另外补上两处最关键的漏网：
- smtp.enabled 原先无 has()，站点设置页保存会把它写成 0
- smtp.from 兜底逻辑会在邮件页之外触发，改为仅在 from 被提交时生效

## 验证：写了一个专门抓这类问题的测试

`_tooling/feedlite/fb_config_guard_test.py`，6 项：

  A 站点设置页保存 → 邮件配置必须全部不变
  B 邮件页保存 → OSS/附件配置必须全部不变
  C 反复交叉保存 3 轮 → 全部配置始终不变
  D 提交残缺表单 → 绝不能把其它配置写空

正常代码 6/6 通过。

## 反向验证（关键）

把 $save 退化成直接写库、并去掉两个分组判断后重跑：

  A1 FAIL  smtp.enabled:1→0; notify.enabled:1→0; ...      ← 邮件没了
  B1 FAIL  attachment.storage:oss→off; oss.enabled:1→0; ... ← OSS 没了
  C1 FAIL  3 轮后同样被清
  D1 FAIL  残缺表单把 storage 写成了 off

现象与用户遇到的一模一样，证明测试确实能抓到，不是假通过。

## 回归

全新安装 33/33、邮件专项 73/73；前台各页状态码正常、无 PHP 错误。
（老基线 fb_e2e_wsl.py / fb_attach_wsl.py 两个脚本已不在仓库，
 属历史遗留，本次以全新安装 + 邮件专项 + 配置守护三套覆盖。）
 2026-11-02 23:36:26 +08:00
laoyang 4033170ad7 修复：跨 tab 保存互相清空配置；补齐全流程邮件通知与统一模板 (#2) 
## 一、用户报「我明明配过 SMTP，怎么全丢了、信也发不出」

**没有重置数据库**（installed_at 仍是 11-01 15:14，oss.*/site_name/admin.username 全在）。

真因是我上一轮「邮件拆独立 tab」挖的坑：站点设置与邮件通知**共用 act=settings**，
而保存函数把 smtp 字段无条件写库：

    foreach ($smtpText as $k) {
        fb_set_setting($k, trim((string)$post($k, \x27\x27)));   // 没提交 → 空串 → 覆盖
    }

在站点设置页保存附件设置时，该表单没有 smtp_* 字段，$post() 取到空串，
于是 host/user/from 被清成空。smtp.pass 因为单独做了「留空=不修改」而幸存，
所以现场是 pass 有值、其余全空 —— 这个组合本身就是 bug 的指纹。

修法：新增 $has() 判断「本次请求是否真的提交了该字段」，没提交就跳过。
按 tab 分两组保护：
- $isSiteForm：站点信息/页脚/附件/OSS，逐字段 has() 双保险
- $isMailForm：SMTP/通知开关，整段 + 逐字段

checkbox 尤其要保护：未提交会被当成「取消勾选」，
在站点设置页存一次就会把「有人回复时通知」全关掉。

## 二、notify.admin_new_thread 是假的（用户说「提交了反馈收不到邮件」）

这个设置项：白名单里有、后台有勾选框，**但没有任何代码实现它**。
grep 只命中三处（白名单/保存/界面），没有一处真正发信。

已在 new.php 提交成功后实现：查新帖 → 取所属软件名 → fb_notify_event(\x27new\x27)。

## 三、补齐全部事件，统一入口

此前只有 reply 和 close 两个事件，且两套模板风格不一致。
新增 fb_notify_event() 统一入口，处理「开关→收件人→节流→发信→日志」。

覆盖 8 类事件：reply / status / approve / hide / close / new。
- status 按状态给不同文案（待处理/处理中/已解决/关闭/不予考虑），
  「不予考虑」语气克制、必须带理由并留申诉入口
- approve / hide 原先完全不发信，现在补上
- 状态没变化时不发信（不打扰用户）

## 四、邮件模板重做

抽出 fb_mail_layout() 统一外壳，所有事件共用：
- table + 内联样式（Outlook/QQ邮箱/Gmail 兼容）
- 600px 卡片、顶部主色条、圆角徽标、字段表、引用块、callout、CTA 按钮
- 响应式（已验 375px 无溢出、无裁切）
- preheader 摘要、纯文本兜底链接、收件人提示

## 五、后台状态按钮（用户要求）

问题详情页顶部一排按钮，点一下立刻生效并自动发信：
「通过并公开」「处理中」「已解决」「不予考虑」「撤下」
- 当前状态对应的按钮置灰
- 「不予考虑」展开内联面板填理由（不用 window.prompt）
- 新增 setstatus 动作；「通过并公开」会同时置可见

## 六、notify_log 加 reason 列

原表只有 reply_id，无法区分事件类型。加 reason 并幂等迁移；
老库 reply_id 是 NOT NULL，非回复事件用 0 表示。

## 验证

邮件专项 73/73：
- 8 类事件模板全部完整 HTML、table 布局、徽标、页脚、无 script
- 8 个主题互不相同；状态徽标文案正确
- 总开关关闭时 admin_new_thread 仍可独立生效
- 节流只作用于 reply/status，close 不受影响
- SMTP 未启用时留失败日志（含 reason 与原因）
- C1-C5：站点页保存后 smtp.host/user/notify.enabled 均未被清空；
  邮件页保存后 oss.bucket 未被清空

反向验证：完整回退两层保护后 C1/C2/C3 全部 FAIL
（host 从 smtp.qiye.aliyun.com 变成空、notify.enabled 从 1 变 0），
证明测试能真正抓到该 bug，不是假通过。

回归：全新安装 33/33、老基线 25/25、附件 22/22。
 2026-11-02 22:57:00 +08:00
laoyang 0365098fa4 修复：空格式白名单反而拒绝一切文件；定位「填 0 时正文图传不上」真因 (#4) 
## 一、定位用户报的「提交反馈里图片不显示」

用户先说正文图不显示、回复的却显示，随后反馈「现在可以了，但之前确实不行」。

真因在 #4 已修掉，但当时没写清楚机制：

    for (var i = 0; i < files.length; i++) {
      if (countOf(kind) >= maxCount) {
        alert("最多上传 " + maxCount + " 个");
        break;                    // ← 整批文件一个都不传
      }
    }

数量上限填 0（本意不限）时，countOf 是 0、maxCount 是 0，
`0 >= 0` 为真 ⇒ 弹「最多上传 0 个」⇒ break 跳出整个循环 ⇒
选中几张就全部丢弃。上传区看起来"正常"（只是弹了个框），
提交后正文自然没有图。

已在线上核实用户新发的那条：aid=2 tid=2 reply_id=NULL，
附件正确挂在主题正文，详情页 .atts 渲染出 1 个 img，media.php 返回 200 / 225KB。

## 二、顺带修同一段里的第二个同类陷阱

    var allowed = (box.getAttribute("data-accept") || "").split(",");
    if (allowed.length && allowed.indexOf(file.type) < 0) { ... 拒绝 ... }

`"".split(",")` 返回 `[""]`，长度是 1 不是 0。
所以「未配置格式白名单」时，allowed.length 判真、indexOf 永远 -1
⇒ 空列表反而拒绝一切文件，这与"没配置=不限格式"的意图相反。

修法：split 后 filter 掉空项。实测：

    normal : allowed=["image/jpeg","image/png"] len=2 blocked=false
    empty  : allowed=[""]                      len=1 blocked=true   ← 旧代码

当前 UI 没有清空 mimes 的入口，现网触发不到，但属于同一类
「空/0 被当成最严格限制」的坑，一并修掉。

## 三、资源版本 14 → 15

🔴 上一轮就是改了 app.js 却忘升版本，浏览器一直用缓存旧 JS，
   导致修复看起来"没生效"。这次改完立刻升，三处引用
   （layout.php 的 css/js、install.php 的 css）都走 FB_ASSET_V 常量。

## 四、新增专项与反向验证

`_tooling/feedlite/fb_attach_zero_js.py`：19 项。
关键设计：数量判断条件**从源码正则抽取**后注入 node harness，
不在测试里硬编码正确写法 —— 否则修复被回退时测试照旧全过，成了假通过。

反向验证（故意把修复回退）：
- 正常版本 19/19
- 回退版本 12/19，B1/B2/B4/B6/B9 全部 FAIL，能准确定位

⚠️ 第一版 harness 的 countOf 返回固定值，导致 B3/B8（"传着传着到上限"）
   假通过。改成动态读递增计数后才是真验证。

回归：全新安装 33/33、附件 22/22、老基线 25/25、约束检查 20/20。
 2026-11-02 10:42:03 +08:00
laoyang 9701291b4e 修复：改了 app.js 却没升资源版本，浏览器一直用旧 JS (#4) 
用户报「图片最多上传 0 个，请先移除已上传的文件」——JS 弹的。

## 根因：不是逻辑没写对，是新代码根本没加载

#4 已经把拦截改成 `maxCount > 0 && countOf(kind) >= maxCount`，
但**忘了把 FB_ASSET_V 加 1**。页面仍然输出 app.js?v=13，
浏览器直接从缓存读旧的 app.js（旧的判断是 `countOf >= maxCount`，
maxCount=0 时 `0 >= 0` 为真，一个都不许传）。

## 修法
FB_ASSET_V 13 → 14。这一改同时覆盖 style.css 与 app.js，
用户下次刷新就会拉到新文件。

## 新增检查脚本
`_tooling/feedlite/fb_asset_version_check.py`：
对比「最后一次改 assets/ 的提交」与「最后一次改 FB_ASSET_V 的提交」，
前者更新就报错。改前端资源却忘升版本这类问题肉眼极难发现，
必须用规则卡住。

用脚本自查当前仓库，确认本提交修完后转为合规。

## 教训
改 assets/ 下任何文件 → **必须同时把 lib/bootstrap.php 的 FB_ASSET_V 加 1**，
这是硬配套动作，写在 README 里但这次没执行到位。
 2026-11-02 09:10:15 +08:00
laoyang 74beaf1163 附件限制全部支持填 0 = 不限制 (#4) 
用户要求：附件存储里所有限制项（几张图、几个视频、大小、总量、保留天数、
每小时次数）都能填 0，0 表示没有任何限制。

## 最危险的地方：填 0 原本是「全禁」不是「不限」

两处逻辑把 0 判成了禁止，语义正好相反：

1. `fb_rate_check()` —— `count < limit`，limit=0 时 `0 < 0` 为假
   ⇒ 每小时上传次数填 0 = 一次都不许传
2. 每帖数量校验 —— `count > max`，max=0 时传一个就超限
   ⇒ 每帖图片填 0 = 一张都不许传

都改成「limit <= 0 直接放行」。

## 校验区间与 input 下限全部放开到 0

| 字段 | 原下限 | 现下限 |
|---|---|---|
| image_max_per_post | 0（但界面上限 20） | 0，上限 1000 |
| video_max_per_post | 0（上限 10） | 0，上限 1000 |
| image_max_bytes | 0.2 MB | 0，上限 1024 MB |
| video_max_bytes | 1 MB | 0，上限 10240 MB |
| total_cap_bytes | 10 MB | 0，上限 1048576 MB |
| retention_days | 1 天 | 0，上限 36500 |
| upload_per_hour | 1 次 | 0，上限 100000 |
| image_max_side | 480 | **保持 480** —— 这是压缩目标边长，不是限制项 |

服务端 `max($range[0], ...)` 不再把 0 拉回下限；input 的 min 一并改 0，
否则浏览器直接拦住连提交都到不了后端。

## 语义冲突：0=不限与「0=关闭该类上传」冲突

原先 `fb_upload_kind_on()` 靠「数量上限是否为 0」判断开关，
0 现在表示不限个数，两者冲突。

按用户选择：**新增独立总开关** `upload.image_on` / `upload.video_on`（默认开），
`fb_upload_kind_on()` 改看开关，不再看数量。
两个新键已加入 `fb_setting_keys()` 白名单（这个坑踩过多次）。

## 前端同步

- `maxCount > 0` 才拦，0 不拦
- 提示文案：数量 0 显示「数量不限」、大小 0 显示「大小不限」，
  不再出现「最多 0 张」这种荒唐文案

## 风险提示（按用户选择用文字告知，不阻止保存）

单张图片/单个视频/全站总量填 0 时，字段下方提示「填 0 时注意：磁盘可能被写满」。

## 验证
0 专项 31/31，关键几条：
- 七项输入框 min 均为 0，image_max_side 保持 480
- 填 0 后数据库里就是 0，没被拉回下限
- **填 0 后行为是放行**：每小时放行、数量不限、总量放行、不清理
- 数量填 0 时上传仍是开的（靠独立开关）
- 取消勾选开关后确实关闭，且与数量填 0 互不干扰
- 非 0 值全部正确（4 张 / 2 个 / 5MB / 50MB / 1024MB / 30 天 / 60 次）

回归全绿：全新安装 33/33、附件 22/22、老基线 25/25、安装向导 60/60、约束检查 20/20。
 2026-11-02 08:55:23 +08:00
laoyang b0e6ac9cd8 邮件 tab 输入框不再预填出厂示例值 (#2) 
用户反馈：「邮件通知这个页面里的那些输入框，当我鼠标点完之后，还是没有把里面的内容删除。」

上一轮（#3）只处理了 prefix 和邮件标题两个字段，**漏了 smtp 整段**。

根因同前：config.example.php 的 smtp 段有全套出厂示例值，
fb_cfg() 合并后表单把它们当"已填内容"显示，用户点进去得先删一遍。

## 本次处理

全部改用 fb_form_val()：数据库里没设过 = 未自定义 = 显示空，示例只留 placeholder。

| 字段 | 出厂值 | 现在 |
|---|---|---|
| smtp.host | smtp.example.com | 空，placeholder 给真实可用的 smtp.qiye.aliyun.com |
| smtp.user | noreply@example.com | 空 |
| smtp.from | noreply@example.com | 空，placeholder「留空则同登录账号」 |
| smtp.from_name | 轻反馈 | 空，placeholder 显示当前站点名 |
| smtp.port | 465 | 空，placeholder 465 |
| smtp.timeout | 15 | 空，placeholder 15 |
| notify.cooldown_seconds | 300 | 空，placeholder 300 |

## 顺带修两个真问题

1. **留空不能存 0**：端口/超时/冷却原先 `(int)$post()`，留空会变成 0，
   0 端口根本连不上、0 超时立刻断。改成留空即删键，回落 config 默认值。
2. **cooldown 出厂值是 300 不是 60**：我一开始按 60 判，导致 300≠60 被当成
   "用户设过"而回显。核对 config.example.php:80 后改正。

⚠️ 注意 cooldown 的 0 是合法值（表示不限制），所以用「空串」区分"没填"，
不能用 0 判断，否则用户真想设 0 会被当成默认。

## 验证
邮件预填专项 33/33：
- 7 个字段 value 全空，示例在 placeholder
- 无任何出厂示例值被预填
- 真实值保存后逐项回显（含 0 这个边界）
- 留空后回显空 + 数据库键被删 + 生效值回落 465/15/300
- 填 0 被正确保留

回归全绿：全新安装 33/33、安装向导 60/60、老基线 25/25、邮件 tab 专项 37/37。
 2026-11-01 19:26:42 +08:00
laoyang 367f78f239 站点设置拆出独立「邮件通知」标签页 (#2) 
用户反馈：「站点设置现在太长了，应该把邮箱设置单独拿出来，做一个标签页。」

原先一个 settings tab 里塞了：站点信息、页脚、邮件通知、附件存储、审核、
存储体检。光邮件那段就 82 行（10 多个字段 + 测试按钮），往下翻很累。

改动：
- 后台导航新增「邮件通知」tab，放在「站点设置」左边
- 邮件那段界面整体搬到新 tab（SMTP 配置 + 通知规则 + 测试发送）
- settings 里彻底移除，不留两处
- tab 白名单加 mail
- 新 tab 有自己的页头（h1 邮件通知）和「← 回站点设置」返回入口

保存逻辑没动：新 tab 的表单仍提交 act=settings，走的还是原来那段
处理代码，所以 SMTP / notify 的写入行为完全不变。

## 兼容
旧链接 admin.php?tab=settings 仍然有效，只是里面不再有邮件字段。
邮件配置数据没动，新 tab 打开就能看到原值。

## 验证
邮件 tab 专项 37/37：
- 6 个 tab 全部 200
- 导航有入口、文字正确
- settings 里 smtp_host/port/pass 均 0 次，无测试按钮
- mail tab 11 个字段齐全 + 总开关 + 页头 + 返回入口
- 保存后回显：服务器、端口、冷却秒数正确；口令显示「已设置」
- 两个 tab 互不干扰

回归全绿：全新安装 33/33、安装向导 60/60、老基线 25/25。
 2026-11-01 17:29:32 +08:00
laoyang e408dc78b8 表单不再预填示例数据，示例只留 placeholder (#3) 
用户反馈：输入框里预填的「示例值」点进去得先删干净才能填自己的，不合理。

必须分清两类，否则会误删真实配置：
- A 类 真实配置（从数据库读出来的）→ 保留
- B 类 出厂示例（代码/配置文件里写死的）→ 清空，示例移 placeholder

本次处理的 B 类：

1. 安装页「网站名称」
   原先回显 config.example.php 里的出厂名「轻反馈」，用户以为要保留。
   现在首次进入为空，仅在表单校验失败重来时回填用户刚才填的内容。

2. 安装页「管理员用户名」
   原先预填 admin，现在为空，placeholder 提示「例如 admin」。

3. 后台「对象键前缀」
   原先显示 fb（来自 config 默认值），现在为空，placeholder「留空即用 fb」。

4. 后台「关闭通知邮件标题」
   原先显示模板「关于你反馈的问题《%s》」，现在为空，placeholder 给出模板。

## 新增 fb_form_val()
config.example.php 里给的出厂默认值和「用户填过的值」在 fb_cfg() 里合并后
分不出来 —— 表单永远显示得出内容。这个函数按「数据库里有没有这条设置」判定：
设过就回显（哪怕值恰好等于默认），没设过就当未自定义、显示空。

## 顺带修复一个真 bug
close_mail_subject 原先留空会存成空字符串，fb_cfg() 返回空串后
sprintf() 得到空邮件标题 —— 用户清空模板就发不出有主题的邮件。
改成留空即删除该设置，回落到默认模板。

## 验证
#3 专项 20/20（含：真实配置保存后必须回显、清空后必须回落默认且不存空串）；
回归全绿：全新安装 33/33、安装向导 60/60、老基线 25/25、约束检查 20/20。
 2026-11-01 16:53:52 +08:00
laoyang f1a81cbaa1 RAM 角色自动探测 + 邮件配置界面 + 每个软件独立主题色 (#1 #2) 
## 1. ECS RAM 角色改为自动探测
原先要用户去阿里云控制台查「实例 RAM 角色名」再手填，纯属多余 ——
机器自己知道答案。

新增 fb_oss_detect_instance_role()：读元数据
GET /latest/meta-data/ram/security-credentials/（末尾带斜杠）拿到角色名列表。
- 兼容单行 / 多行 / JSON 数组三种返回
- 未配置角色时 fb_oss_instance_creds() 自动探测，不再报「未配置」
- 后台改成只读展示「已绑定：xxx」，手填入口收进「高级」折叠里
- 保存时留空 = 自动探测后写入，不存空值
- 探测失败给出可操作原因（没绑角色 / 不在 ECS 上 / 元数据被禁用）

## 2. 邮件配置界面（原先完全缺失）
lib/mailer.php 有完整 SMTP 实现，但后台一个输入框都没有，
只能改 config.php —— 用户装完根本找不到地方配。

根因有两层：
- fb_setting_keys() 白名单里没有任何 smtp.* / notify.* 键，
  就算加了表单，fb_set_setting() 也会把值全部丢弃
- 设置页只有「站点信息」「附件存储」两个区块

补上：白名单 15 个键 + 后台「邮件通知」区块
- SMTP 服务器/端口/加密方式（SSL/STARTTLS/不加密）
- 登录账号/密码（留空不修改，避免每次重填）
- 发件地址/显示名、超时、SSL 校验
- 通知规则：回复通知、每次回复都通知、新反馈通知管理员、发信冷却
- 「发送测试邮件」按钮，AJAX 发完就地显示成功或失败原因，
  不用保存再靠猜

## 3. 每个软件一个主题色
需求：从短链接进不同软件，颜色不同，一眼区分。

- software 表加 color 字段（幂等迁移）
- 全站配色靠 --brand / --brand-600 / --brand-soft 三个变量，
  按软件覆写这三个即可，不用为每个软件写一套 CSS
- fb_color_variants() 由主色推出深一档（×0.85）与浅一档（往白混 88%）
- 未配色的软件按 id 从 8 色调色板取默认色，保证同站不撞色
- 后台：颜色选择器（原生取色 + 8 个预设 + 用默认）
- 前台：index / new / thread 都按当前软件注入主题色，
  meta theme-color 也跟着变

验证：三功能专项 30/30；新旧回归全过
（全新安装 33/33、老基线 25/25、附件 22/22、安装向导 60/60、约束检查 20/20）
 2026-11-01 16:39:09 +08:00
laoyang c19e475e85 修复：附件总量上限填 10240 被浏览器拦住（step 与 min 冲突） (#1) 
用户反馈「全站附件总量上限填 10240 不行」。

根因：input 写成 step="16" min="10"。
HTML 的 step 是从 min 起算的 —— 合法值只有 10、26、42、58…（10 + 16n）。
10240 不在这个序列里，浏览器直接判为非法值、拒绝提交。

更糟的是这不是个例：1024（1G）、2048、4096、8192 全都不合法，
只有 10/26/42 这种怪数字能填进去。这个 bug 从该字段上线就存在。

修法：
- step="16" → step="any"，允许任意数值
- 补 max="100000"，与服务端 [10, 100000] 区间对齐，
  避免用户填 999999 被服务端静默截断成 100000

顺带排查另外两个容量字段，确认没事：
- 图片单张上限 min=0.2 step=0.1 → 0.2 起步正好对齐，0.5/1/5/10 都合法
- 视频单个上限 min=1 step=1 → 整数都对
只有总量那一个字段踩了坑。

新增 tools 级检查脚本（_tooling 侧 fb_input_constraint_check.py）：
按 HTML 规范逐条验算每个 number 输入框的 min/max/step 是否放行
「默认值」与「常见取值」，并核对前后端区间是否一致。19/19 通过。
这类错误肉眼看不出来，必须用规则算。

验证：约束一致性检查 19/19；服务端 MB↔字节往返一致（含 10240）。
 2026-11-01 15:26:08 +08:00
laoyang 1434a6dfb6 修复：英文标识留空真能自动生成；表单必填前端就地提示不刷新 (#1) 
## 问题 1：文案说「留空自动生成」，实际却报错
界面上英文标识写的是「留空自动生成」，且不带红星；但纯中文名
（如「同步日历」）经 slugify 过滤后是空串，服务端照旧报「请填写英文标识」。
文案与行为自相矛盾，用户不明所以。

根因：fb_sw_slugify() 只保留 ASCII，中文全被过滤掉。

修法（不靠加红星了事）：给 slugify 加兜底前缀 + 序号
- 软件：中文名 → sw<序号>（如 sw2）
- 分类：中文名 → cat<序号>
- 编辑时留空 = 保持原标识，不因改名把已有网址打散
- 纯英文名行为不变（FeedLite → feedlite）

实测：同步日历 → sw1 / 我的软件 → sw2 / FeedLite → feedlite

## 问题 2：必填项没填，整页刷新才看到错误
原先完全靠服务端校验：提交 → POST → 整页重刷 → 页面顶部弹一条错误。
用户视角就是「什么都没填，页面闪了一下」。

新增 bindInlineValidate()（assets/app.js）：
- 给 form 加 data-validate 即启用，零配置
- 就地校验：字段下方显示红框 + 原因，聚焦并滚到可见
- 用户一改动立刻撤掉提示，不一直红着
- 规则取自原生 required / minlength / pattern / type=email

🔴 关键实现细节：用**捕获阶段**监听，并调 stopImmediatePropagation()。
因为 bindNoDoubleSubmit 会在 submit 时禁用按钮 5 秒，若校验排在它之后，
被拦下的表单按钮会被锁住，用户以为点坏了。所以校验必须先跑且拦住它。

## 服务端仍保留兜底
JS 被绕过（禁用脚本、直接构造请求）时，后端照样拒绝空用户名、短口令。

## 顺带收敛资源版本
app.js?v=5 与 style.css?v=N 原先各自写死，已统一到 FB_ASSET_V（升到 11）。
加上前一轮的 layout.php / install.php，现在全站只有 bootstrap.php 一处定义。

验证：
- 标识生成与前端校验专项 21/21
- 全新安装 33/33、老基线 25/25、附件专项 22/22
- 安装向导 60/60、后台管理 30/30
 2026-11-01 15:21:27 +08:00
laoyang b835afcd04 data/uploads 改为由 PHP 自动创建并自补防护，不依赖部署账号建目录 (#1) 
## 问题
部署时用 btops 建 data/ 与 uploads/，属主成了 btops:btops，Web 用户 www 写不进去，
安装向导直接报「目录不可写」，还得请人用 root 手工 chown —— 这不该让用户干。

## 修法：让 PHP 自己建
PHP 以 Web 用户身份运行，它建出来的目录属主天生就是 www，不需要任何 chown。
- 部署脚本不再创建 data/ uploads/（只建 assets/ lib/）
- 首次访问时 fb_db_init() 自动 mkdir data/，并立刻补防护文件
- uploads/ 由 fb_local_ensure_dir() 同样自动建 + 补防护
- 安装向导的环境体检 mkdir 之后也立刻补防护，不留空窗期

## 新增 data/ 防护文件自动生成
原先只有 uploads/ 有自动防护，data/ 没有 —— 数据库目录裸奔。
新增 fb_db_ensure_guard()，写 .htaccess（拒绝直读，禁 db/db-wal/db-shm/sqlite/php）
+ index.html 占位，带 `# fb-data-guard: vN` 版本标记，规则升级时整份重写。

## 顺带确认
站点根 .htaccess 已有全局兜底（拒绝 .db/.log/.md/.bak 等直读 + Options -Indexes），
即使某个目录暂时缺 .htaccess，/data/ 和 /data/feedback.db 也是 403。
现在是双保险，不依赖单点。

验证（WSL 真实环境）：
- 全新安装 33/33、老基线 25/25、附件专项 22/22、安装向导 60/60
- data/ 与 uploads/ 均由 PHP 自动创建，属主即运行用户
- 两者 .htaccess 自动生成并带正确版本标记（v1 / v2）
 2026-11-01 15:07:53 +08:00
laoyang 1c2e8d5e65 安装向导：装完自动删除 install.php；站点根只读不再阻断安装 (#1 #2) 
## 装完自删
install.php 是可写文件，留着等于长期暴露一个「重装入口」。
现在安装成功后自动 unlink 自己，不再要用户手动删。

两种结果都如实告知，不假装：
- 删除成功 → 成功页显示「已自动删除」
- 删不掉   → 显示「没能自动删除」+ 具体原因（目录不可写 / 属主不符）+ 手工处理命令
安装本身不受影响：清理失败不算安装失败。

## 🔴 修掉一个越权动作（本轮最要紧的修改）
初版为了「尽量删掉」，先 @chmod(dirname($self), 0755) 再 unlink。
这等于程序自己把「站点根只读」这个安全设置拆掉了 —— 管理员有意设成只读的目录
被 PHP 改回可写，然后文件就被删了。既违反管理员意图，也让「删不掉」这个真实场景
永远测不出来（我第一版测试就是这么被骗过去的）。

删除失败就如实报告，不准硬删。

## 站点根只读不再阻断安装
原先环境体检把「站点根可写」列为硬性要求，只读就红叉、禁止提交。
但这没道理：config.php 写不进去时，设置会全部落到数据库 settings 表，功能一样。
反过来，站点根只读是更安全的做法。

现在 data/ 与 uploads/ 可写仍是硬要求，站点根只读只显示为提示（不影响判定）。

## rename 兜底收窄
只在目录可写时才试 rename（目录不可写时 rename 同样失败，
硬试会在站点里留下 .deleted.xxxx 垃圾）。改名成功但删不掉则还原。

验证：
- 自删 A 场景（目录可写）→ 文件已删，页面提示「已自动删除」
- 自删 B 场景（目录只读）→ 文件保留，提示「目录对 Web 用户不可写」，安装仍成功
- 全新安装 33/33、老基线 25/25、附件专项 22/22、安装向导 60/60
 2026-11-01 12:55:08 +08:00
laoyang 7a578fac47 静态资源版本收敛到 FB_ASSET_V 常量 (#1) 
原先 layout.php 与 install.php 各写一份 style.css?v=N，改样式时只改一处，
另一处会漂移 —— 实际就发生了：首页 v=10、安装页还是 v=7，两页样式不一致。

现在统一在 lib/bootstrap.php 定义 FB_ASSET_V，两处都引用它。
以后改 assets 下的 css/js，只改这一个数字。
 2026-11-01 12:47:41 +08:00
laoyang 9b822d2d9a 安装向导：加管理员用户名，精简为填表即装、装完进首页 (#1 #2) 
## 管理员账号（用户名 + 口令）
原先只有口令，没有用户名。现在两者都有：
- 用户名词入库 settings 的 admin.username（2~32 位，字母数字下划线点连字符）
- 口令仍是 bcrypt 哈希存 admin.password_hash，明文不落任何文件
- 登录校验 fb_admin_verify_login()：用户名或口令任一不对都返回同一句
  「用户名或口令不正确」，且用户名错时也照常跑一次 password_verify，避免用耗时探测账号
- 向后兼容：老部署只设了口令没用户名时，仍可只填口令登录，
  并在登录页提示补一个用户名

## 安装向导精简
按用户要求「没数据就初始化，填完进主页」：
- 必填只剩 4 项：网站名称、管理员用户名、口令、确认口令
- 站点描述 / 官方邮箱 / 站点根地址改为 hidden（可留空自动探测）
- 密钥、令牌原本就自动生成
- 安装成功后展示网站名称与用户名，2 秒自动跳首页，也有按钮
- 按钮文案改为「完成安装，进入首页」

## 修掉一个真实 bug
首页把软件说明当成站点描述，导致「软件有 note 时站点描述被顶掉」。
两者是不同的东西：站点描述是全局设置必须始终显示，软件说明另起一行补充。
老基线 D6「首页描述变为新描述」就是被这个 bug 弄失败的。

## 另一个坑
admin.username 忘了加进 fb_setting_keys() 白名单，fb_set_setting() 会静默丢弃，
表现为「安装时填了用户名，装完却没有」。已补。

验证：
- 全新安装流程 32/32（真空站：无 config.php、无 data/*.db）
- 老基线 25/25、附件专项 22/22、安装向导 60/60
- PHP 8.5 全部入口 0 弃用
 2026-11-01 12:39:20 +08:00
laoyang 55d2dfa46b 后台管理界面：软件/分类/状态可配，反馈可改挂归属 (#1) 
## 新增 lib/admin_taxonomy.php
- 软件：增删改、排序、启停；新增时自动预置 Bug/功能建议/其他 三个分类
- 分类：在选定软件下增删改、排序、启停
- 状态：改名、改「给用户看的话」、排序、启停；标识不可改（历史数据靠它对应）
- 反馈改挂：th_move，可把反馈移到别的软件/分类，跨软件的非法分类会被拒

## 安全与边界
- 所有动作走 CSRF 校验（沿用现有机制）
- 不能删最后一个软件 / 没有分类的软件至少要留一个启用分类
- 有反馈挂着的软件或分类不能删，提示改为停用（停用后前台消失、数据保留）
- th_move 加入 fb_admin_is_taxonomy_act 白名单，否则会被「问题不存在」静默吞掉

## admin.php 接线
- 引入模块 + 动作分发 + tab 白名单加 taxonomy/statuses + 导航两项
- 前置检查放行不依赖 $t 的动作（否则新增软件报「问题不存在」）
- 全部问题列表：加软件筛选、分类跟着软件走；修掉三处仍在用旧
  fb_statuses()/fb_categories() 的遍历（那会渲染出错）
- 详情页加「归属」表单，软件徽章可显示

## 其他文件
- api.php：状态/分类改数据库；新增 ?sw= / ?software_id= / ?cid= 过滤，
  老的 ?category=<slug> 仍可用（在所属软件内解析）
- thread.php：详情页显示软件与分类徽章
- config.example.php：移除 categories / statuses，改由数据库管理

## 修掉两个真实 bug
1. 移除配置后出厂分类兜底只剩 4 个，漏了「同步问题」—— 建库后核对数量才发现
2. th_move 不在白名单，POST 后返回 200 却静默不生效

验证：后台 e2e 29/29；改挂与联动 13/13；PHP 8.5 全部入口 0 弃用；
19 个 PHP 文件语法全过。
 2026-11-01 12:03:11 +08:00
laoyang 59f7466ae4 多软件归属：软件→分类两级，配置全部入库 (#1) 
原先分类写死在 config.example.php，后台改不了；也没有「软件」概念。
现在改为数据库驱动的两级结构，后台可配（管理界面待做）。

## 数据层（lib/db.php）
- 新增 software / categories / statuses 三张表
- categories.software_id 外键：每个软件有自己的分类集合，可同名互不干扰
- threads 加 software_id / category_id；老 category 文本列保留不删（可回退）
- fb_db_migrate_taxonomy() 幂等迁移：建表 → 空表灌初始数据 → 回填老帖子

## 迁移实测
- 老 5 个分类（使用问题/Bug 反馈/功能建议/同步问题/其他）原样落进默认软件
- 老帖子按 category slug 回填 category_id，匹配不到的留 NULL

## 状态（5 个）
待处理 / 处理中 / 已解决 / 已关闭 / 不予考虑(wontfix)
每个状态带 user_note「给用户看的话」，后台可改，将进邮件正文。
待处理 = 刚提交：您提交的反馈已收到，我们正在处理中。

## 前台
- index.php：软件切换条 + 分类 chip（一级软件、二级分类）
- new.php：选软件、分类下拉随软件变、服务端校验分类归属
- URL：?sw=<slug>&cat=<slug>；老链接 ?cat=xxx 解析不到时退回全部，200 不 404

## 界面一致性
按用户要求去掉「单软件时隐藏软件选择器」的逻辑：
所有界面一致，配一个就列一个，配多个就列多个。

## 兼容
fb_categories() 现在必须传软件 id；fb_statuses() 返回行数组，
另有 fb_status_keys() 取 key=>name 映射。

验证：WSL 内临时实例实测——单软件显示 1 个软件条；两软件各显示
自己的分类集合与帖子，互不串；无 PHP 警告/致命错误。
 2026-11-01 11:35:55 +08:00
laoyang 690228e7c1 安装体检：修正 fileinfo 说明（只影响本机存储模式） 
原先写「上传校验会更严格」是不准确的：OSS 存储模式下，附件校验走对象存储
返回的 Content-Type（lib/attach.php 的 oss 分支），根本不调用 finfo。真正用到
fileinfo 的只有本机存储分支（lib/attach.php 的 local 分支、media.php）和
media.php 的本机附件 MIME 探测。

改动：
- install.php 体检项说明改为「按文件内容识别附件类型（仅本机存储模式用得上）」，
  缺失文案补上「不影响安装」，补救提示写清 OSS 模式以对象存储返回的类型为准、
  与本扩展无关，避免管理员误以为装个扩展就补了个安全缺口。
- README 同步区分两种存储模式；补充两点排查经验：
  面板显示「有」不等于运行中的进程已加载，要看 php.ini 里的 extension 行；
  且改完 ini 必须重启/重载 PHP-FPM 才生效（reload 即可，不必 restart）。

验证：php -l 双版本通过；安装向导 60/60、主回归 25/25、PHP 8.5 兼容 19/19；
线上部署 17/17，6 个文件 md5 逐个一致，冒烟全绿。
 2026-10-23 09:07:39 +08:00
laoyang 23772b37ab 安装体检：把 fileinfo 列为推荐扩展 
新装一套 PHP（尤其宝塔里的 8.5）时 fileinfo 常常默认没开，此时
上传的类型校验只能按「扩展名 + 浏览器声明的 MIME」核对。代码本身
有回落链、不会报错，但用户无从得知这层弱化，因此在安装体检里显式
列出，并说明开启后的收益。

- install.php：可选扩展支持 [说明, 缺失文案, 补救提示] 三元组
- README：扩展清单补 fileinfo，并提示换 PHP 版本后要复查一次
 2026-10-23 08:42:47 +08:00
laoyang 6135e7b890 兼容 PHP 8.5：消除全部弃用调用 
PHP 8.5 把 curl_close()/finfo_close() 这类"空操作函数"标为弃用，
并把预定义局部变量 http_response_header 标为弃用（编译期判定，@ 与三元短路都压不住）。

- 句柄关闭收进 fb_curl_close()/fb_finfo_close()：仅 PHP < 8.0 真正调用，
  新版本直接跳过（8.0 起句柄随引用计数释放），保留 7.4 兼容
- 响应头读取改用 http_get_last_response_headers()（8.4+）；
  老版本经 get_defined_vars() 从作用域变量表取，源码不再出现已弃用标识符
- 新 API 是全局状态，用「请求前基线」比对，避免把上一次的残留头当成本次结果
- 安装体检与 README 的推荐版本区间更新为 8.1~8.5

验证：PHP 8.5.12 下五套测试全绿（25/25、22/22、60/60、7/7、反向 4 组全被抓住），
error_log 零条弃用记录；PHP 8.4.25 同样全绿。
 2026-10-23 08:23:55 +08:00
laoyang 5006d54be3 附件读取统一走 media.php 代理，真实地址不再暴露 
无论附件存在本机 uploads/ 还是 OSS 私有桶，前台给浏览器的地址现在完全一致：
media.php?k=<对象键>。界面上不再出现 uploads/ 真实路径，也不出现任何 bucket /
endpoint / 签名痕迹。

- lib/attach.php：新增 fb_attach_proxy_url()，fb_attach_url() 与
  fb_attach_thumb_url() 的本机分支一并改走代理（地址不落库、渲染现算，
  对历史附件立即生效，无需迁移）。
- uploads/ 整目录禁止 Web 直读：附件只能经 media.php 出，真实物理路径
  即便被猜到也取不到，同时绕不开 media.php 的可见性鉴权。
- 规则版本化自动升级：.htaccess 内埋 `# fb-local-guard: vN`，
  旧版规则在任意请求时由 PHP（目录属主）整份重写。之所以不能靠部署覆盖：
  部署账号对 uploads/ 无写权限，只有程序自己能改。
- 随包 uploads/.htaccess 改为程序产出的逐字节副本，并加断言防漂移
  （否则线上会被自动升级覆盖，随包那份形同虚设）。
- 顺带修复真实源码泄漏：config.php.bak_<时间戳> 这类「非 .php 结尾、
  但含源码」的备份文件此前可被公开下载。加固根 .htaccess：
  去掉正则结尾锚点、补 .php[.\-_] 兜底、点名拒绝 config.php / oss.sts.php。
- media.php / upload.php / admin.php / README.md：文档与响应头同步。

验证：php -l 19 文件 0 失败；主回归 25/25、附件专项 22/22、安装向导 60/60、
统一代理渲染 7/7、反向验证 V1-V4 全被抓住；线上冒烟 30/30、
线上统一代理真机 13/13（OSS 私有桶 + 内网 endpoint 下上传→代理读回→
Range 206→伪造键 403）。
 2026-09-28 23:33:45 +08:00
laoyang 27187b38f1 页脚入口与安装向导；加固管理员口令存储 
需求落实：
1. 页脚常驻「管理后台」链接，不用再手敲 admin.php。
2. 页脚「由 FeedLite 驱动」中的 FeedLite 改为超链接（指向开源仓库）；
   后台新增「页脚」设置组，可关闭整句（关闭后只留管理后台链接），也可改链接地址。
3. 管理员口令存储方式在后台如实展示：数据库 settings.admin.password_hash，
   存 bcrypt 单向哈希（不可逆），明文不落盘。
4. 新增安装向导 install.php：data/ 下没有数据库时自动 302 引导；
   体检环境 -> 填站点信息与口令 -> 生成 config.php -> 建库建表 -> 完成。

顺带修掉一个真实安全隐患：
  config.php 里的出厂占位口令 CHANGE_ME_admin 原先可被当作有效口令登录后台
  （等于公开仓库里就写着线上后门口令）。现改为占位/空值一律拒绝，
  未设口令时后台明确提示去安装向导，不再含糊报「口令不正确」。

实现要点：
- 新增 fb_cfg_file()：只读配置文件、不叠加 settings 表、绝不触达数据库。
  「是否已安装」以数据库文件是否存在为判据，而 fb_cfg() 读 settings 会触发
  fb_db() 就地建库 —— 那会把安装态自己造出来，所以判定必须走不碰库的通道。
- bootstrap 只在已安装时建库；未安装则 302 到 install.php（CLI 下报错退出）。
- fb_settings_flat() 在未安装时直接返回空，杜绝任何隐式建库。
- install.php 用文本级替换生成 config.php，保留全部注释与 OSS/SMTP 段落；
  生成的 PHP 用 token_get_all(TOKEN_PARSE) 校验后才落盘。
- 页脚链接只放行 http/https，后台保存时校验（防 javascript: 伪协议）。
- style.css 页脚行改 flex，版本号 v6 -> v7。

验证：
- php -l 全量通过；现有回归 25/25、附件专项 13/13 保持通过。
- 安装向导专项 60/60（含「明文口令未写入任何文件」「数据库字节里搜不到明文」）。
- 反向验证：撤销三处修复后对应断言确实失败（断言非装饰）。
- 几何检查：本机 15/15 + 页脚专项全过；线上真实 URL 15/15 + 页脚专项全过。
- 线上真机冒烟 22/22。
 2026-09-28 22:53:55 +08:00
laoyang 1401ad899b OSS 附件改为私有桶+内网Endpoint+服务器代理架构 
背景：桶为私有、且只用内网 Endpoint（外网不可达），浏览器既无法直传、
也无法直连。原「浏览器直传 + 签名URL直连」两条路都失效，改为全站代理。

lib/oss.php:
- endpoint 自动转内网(*-internal)，use_internal_endpoint 开关控制，内网走 http
- 移除浏览器直传凭证(PostObject)，改为服务器端 PUT(流式 fb_oss_put_file)
- 新增 fb_oss_stream_get 流式读取(回调式，支持 Range，不整文件进内存)
- 签名支持 x-oss-process 子资源 + Authorization 头签名(Content-Type 入签)
- 新增 fb_oss_probe 连通性自检、fb_oss_error_text 错误归因(含跨地域提示)

media.php(新增): 附件代理输出，鉴权边界=对象键须在本站附件表(或本人待入库
  登记)且帖子对访客可见，防止本站沦为能读整个共用桶的开放代理；透传 Range。

upload.php: local/oss 统一走两步(领键→action=put)，OSS 模式由服务器代理 PUT。
lib/db.php: 新增 pending_attachments 表 + idx_att_key 索引(迁移幂等自动建)。
lib/attach.php: 待入库登记(mark/clear/mine/gc)，解决上传后入库前的预览鉴权。
cron.php: 清理过期待入库登记 + 桶连通性自检输出。
admin.php: 设置页加「使用内网 Endpoint」开关、存储体检显示实际连接地址与探测按钮。
README/config: 全面更新为代理架构(无需CORS、无需自定义域名、同地域要求)。

验证：本地 e2e 25/25 + 附件专项 13/13(含防开放代理/Range/内网改写)；
线上真机上传→内网PUT→media.php代理读回→Range 全通过。
 2026-09-28 22:12:28 +08:00
laoyang cede838b5e FeedLite 初始提交：通用轻量级反馈系统（PHP + SQLite，零依赖） 
- 前台：问题列表 / 详情 / 发布与回复（趣味问答验证码、蜜罐、IP 限流）
- 后台：先审后显、站点设置（站点标题/描述、附件存储、OSS 参数）、操作日志
- 附件：关闭 / 本机硬盘 / 阿里云 OSS 浏览器直传（ECS 实例 RAM 角色）三种模式
- 品牌资源：全套图标（favicon.ico / SVG / PNG 各尺寸 / manifest）
- 安全：CSRF、session 加固、.htaccess 屏蔽敏感文件、口令仅存哈希
- 配置：config.example.php 为模板，config.php 不入库
 2026-09-28 20:34:37 +08:00