laoyang/FeedLite
1
0
Fork 0
Code Issues 5 Pull Requests Actions Packages Projects Releases Wiki Activity
50 Commits 1 Branch 0 Tags
ad1b0eedf470ef5fc117df59234fe3fe2c91b66b
Commit Graph
13 Commits
Author SHA1 Message Date
laoyang ad1b0eedf4 主题色改为自绘取色面板（任意取色）；图标上传加即时预览与状态提示 
一、颜色不够丰富 → 点击弹取色面板
  用户：「还是不行，颜色还是不够丰富。让用户选择吧：点击之后弹出一个颜色选择器。」
  原来只有一个原生 <input type=color> 小方块，用户不知道能点，
  而且系统面板各浏览器样式不一、只能取纯色。
  改成自绘面板：
    色相/饱和度渐变板（Canvas）+ 明度滑块 + 十六进制输入 + 确定
    12 个预设圆点降级为快捷方式，真正的能力是任意取色
  交互：点色块弹出（下方空间不够自动翻上方）、板内拖动实时更新、
        十六进制可手输、点确定或面板外关闭、Esc 关闭

  ⚠️ 光标定位踩了两个坑，都写进注释了：
    ① 不能用 canvas.offsetLeft（相对 offsetParent，受父级 padding 影响，
       实测算出 236px 超出画布宽度 226px）；要用两个 getBoundingClientRect 相减
    ② canvas 显示尺寸受 CSS width:100% 影响，≠ 内部像素 220×150，
       必须用 rect.width 而不是 canvas.width

二、图标上传没反馈
  用户：「上传的图标没有显示，也没有上传成功、失败之类的提示信息。」
  后端逻辑完整（格式/大小/尺寸/存储模式都校验了），问题在**前端零反馈**：
  裸 <input type=file>，选完文件什么都不发生，而提示条在页面顶部容易被错过。
  加了 bindIconUpload()：
    ① 选中文件立刻 FileReader 本地预览，不等提交
    ② 显示文件名 + 尺寸 + 大小，让用户确认选对了
    ③ 选之前就拦掉明显不合格的（格式/超 2MB/小于 32×32/空文件）
    ④ 非正方形给出警告（显示时会被裁切）
  ⚠️ 前端校验只是体验优化，绝不能当安全边界 ——
     真正的校验仍在 PHP 的 fb_icon_store_upload() 里。

验证（用独立测试页 + 浏览器实测，不登录后台、不动数据）：
  面板初始隐藏 → 点击后 248×246 出现
  Canvas 四角像素分别为灰白/蓝/黑 → 渐变确实画出来了
  板上取色 → 隐藏字段 #2178d9 同步到按钮文字/十六进制框/预览色
  点预设 → #2B822E；手输 → #a020f0；色相滑条 120° → #20f020
  光标中心 (238,54) 落在画布区域 (11..237, 11..161) 内
  4 个路由 200
 2026-11-04 18:52:45 +08:00
laoyang 8763e8e17f 回复框去掉管理员口令与处理状态；带 token 时昵称/邮箱锁定为只读 
用户三个问题，本质是同一件事：token 就是身份凭证，那就不该再让表单声明身份。

一、去掉管理员口令 / 处理状态
  用户：「回复这个地方，下面有个管理员口令，还有处理状态，都不要填了，
        只保留回复内容，加上人机验证就可以了」
  - 删掉表单里这两块，删掉 admin-pw/admin-status 的 CSS 与 bindAdminToggle 的 JS
  - 管理员身份只认后台登录态（fb_is_admin()），不再从公开表单收口令
  - 状态流转只在后台详情页那排按钮里做

二、带 token 时昵称/邮箱锁定为只读
  用户：「如果他带着 Token 进来之后邮箱又让他改了，我们又没办法知道谁是谁了」
  - 有 token = 已证明是提交人本人，表单不再让填昵称/邮箱，
    改为显示只读的「回复身份」块（原昵称 + 原邮箱）

三、服务端强制（关键）
  🔴 前端设成 hidden 是不够的 —— hidden 可以被改：
     谁拿到链接、改个 email 提交，这条反馈的联系人就变成他的了。
     所以服务端在 isOwnerView 时**直接丢弃 POST 里的 name/email**，
     一律以库里那条帖子的 author_name / author_email 为准。
     身份校验必须在服务端做。

验证（这次确保请求真的通过人机验证，不是被验证码挡住造成的假通过）：
  题目「2 乘以 7」答 14 → 跳转到 #r3，回复确实入库；
  提交的是 黑客改名 / attacker@evil.example，
  实际入库 name=jervis email=zeussun@msn.com —— 伪造的两个字段都被丢弃。
  另外：无 token 的普通访客仍可自由填昵称邮箱；全站已无「管理员口令」残留。
  测试回复已清理，reply_count 已同步。
 2026-11-03 10:02:57 +08:00
laoyang 2f28b1e3a9 下拉菜单改成极简小浮窗（参考家书 FamilyBook 的 popup 做法） 
用户第三次指出这个按钮不对，原话：
  「你不用做那么复杂，就是参考一下 FamilyBook 里边那个设置按钮，
    非常简单的，点了之后就拉下来一个很窄的一个框，
    把所有的内容都铺在上面就可以了」

去看了 FamilyBook 的实现：顶栏那颗按钮是 bindSheet + SheetSize.FIT_CONTENT，
即「内容多高就多高」的小浮层，不是整幅面板。

改法：
- 面板从「left:0 right:0 铺满宽度 + 遮罩 + 锁滚动」
  改成「贴按钮右下、min-width 172px、内容撑高、圆角 12px 小浮窗」
- 删掉 sw-mask 遮罩、删掉 body overflow 锁定
- 面板移进 .topbar .wrap（flex 内），以它为定位参照，右对齐按钮
- 删掉菜单里「选择软件」标题（按钮本身已经说明用途）
- 条目字号降到 14px、图标 18px、内边距收紧，贴合窄框
- 「当前」标记从胶囊缩成 6px 小圆点，窄框里不占地方
- 按钮简化：去掉边框与三横线变×的动效，只留 hover 浅底

实测（CDP 真实浏览器）：下拉框 172×138px，仅占视口宽 13.7%，
右边缘与按钮相差 4px；390px 与 1280px 两种宽度下各 15 项断言全过
（浮窗非整幅、无遮罩、未锁滚动、贴按钮下方、右对齐、
高度由内容决定、有圆角边框、条目纵排同x、y递增、点外部可关）。
 2026-11-03 09:25:41 +08:00
laoyang 28d28ad51c 软件徽标带图标+主题色；标题用软件色；删冗余欢迎语；抽屉改竖排覆盖 
用户四点要求：
1. 待审核标题前的软件名要带图标
2. 每个软件配了颜色，徽标与标题都应显示该颜色
3. 「欢迎在这里反馈使用问题、提出功能建议」这类话没意义，全部删掉
4. 右上角三横线抽屉：不要宽屏横排/窄屏竖排两套，
   统一竖排并把下面内容盖住，简单一点

改动：
- 新增 fb_software_chip()：软件徽标带图标 + 该软件主题色
  （原来一律固定蓝色 #eef2f8/#2b4a74，等于白配了颜色）
  配 fb_color_soft()/fb_color_line() 由主色推导同色系浅底与描边
  替换 admin.php 两处、thread.php 一处（原来是 badge 套 badge，双重边框）
- 顶栏标题与内容区标识都用软件主题色（PHP 内联 --swc 变量）
- index.php 不再渲染 site_desc（配置项保留，后台仍可编辑）
- 抽屉改为统一竖排 absolute 浮层 + 遮罩盖住正文，删掉宽屏横排分支
  打开时锁背景滚动，点遮罩/Esc/再点按钮都能关
  .topbar 作为定位参照（sticky 即可）

顺手修：fb_hex_to_rgb 的三位简写展开前要先校验字符，
否则 zzz 这类非法值可能被误展开（本次测试用例选错才发现校验不够严）

验证：3 个软件 chip 的图标/名字/主色/浅底/描边全部正确，
无图标退回字符、XSS 转义通过、颜色工具函数 6 项通过；
CDP 真实浏览器在 390px 与 1280px 两种宽度下各 13 项断言全过
（绝对定位、在顶栏下方、铺满宽度、条目纵排同x、y递增、
层级高于正文、遮罩同步显隐、可关）；
三个软件标题色分别 #b4553c / #6a4c93 / #0057b8；全部路由 200。
 2026-11-03 09:20:14 +08:00
laoyang 2ef119f7cb 标题字号折中；软件选择移入右上角汉堡菜单 
用户反馈三点：
1. 顶栏图标太大（56px）
2. 顶栏文字反而比内容区还小 —— 主次颠倒
3. 不要再整页显示「选择软件：」，改成右上角三横线按钮，点开下拉选

字号标准（用户给的基准）：
  「选择软件」标签 13.5px，比它大两号 ≈ 17px。
  → 顶栏 17px 字 / 30px 图标；内容区 15px 字 / 24px 图标。
  这样 17 > 15，层级正确。

   之前两轮都搞错了：
   - 先给顶栏 46px 图标 + 22px 字：图标过大
   - 再给 56px + 26px：更大
   - 而且内容区当时是 30px，比顶栏还大，视觉上「上面比下面小」

软件选择改造：
- 顶栏右侧新增汉堡按钮（三横线，展开变×）
- 抽屉面板放在 header 内、正文之上，默认 hidden
- 列出软件：图标 + 名字 + 当前项标记
- index.php 删除整行「选择软件：」+ chips
- new.php 表单内也删除那排 chip（同一选择不该出现两次）
- 交互：点击展开/再点收起/点外部关闭/Esc 关闭
- 宽屏抽屉横向排列，窄屏纵向

验证（CDP 驱动真实浏览器）：
汉堡按钮存在、初始收起、点击展开、aria 同步、软件条目与当前标记齐全、
再点收起、点外部关闭 —— 全部 PASS；
顶栏字号 17px > 内容区 15px，页面无裸露 ?>；
全部路由 200；窄屏 15px/13px 层级仍正确。
 2026-11-03 08:51:20 +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 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 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 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 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 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