tamakyi
b9060c982b
feat(notify): 新增站级 Webhook 与用户级 Telegram 通知通道
...
在现有邮件通知之外补两条广播/点对点通道：
- 站级 Webhook（[notify] webhook_url）：新提问 / 新回答 / 新追问 / 新私聊 /
新投票回复统一 POST JSON 到通用 Webhook（Discord / Slack / 企业微信机器人等）。
消息体同时带 content（Discord 直接可用）与结构化 event/title/body/link 字段。
- 用户级 Telegram（[notify] telegram_bot_token + users.telegram_chat_id）：箱主
自填 Chat ID，新提问 / 新投票回复点对点推送。
设计约束：通知是「尽力而为」旁路 —— 任一通道发送失败只记日志、不向上抛错，
绝不影响提问/回答的主流程；通道未配置时静默跳过。发送放在 shared.SafeGo 异步
执行，与现有邮件通知同一条路径。
6 处业务触发点接入 notify；私聊消息保留仅邮件（已有 5 分钟节流，避免广播刷屏）。
profile 页新增 Telegram Chat ID 输入框 + 四语言字典。app.sample.ini 加 [notify] 段。
测试覆盖 webhook 的 JSON 结构与未配置时的静默跳过。
2026-10-29 19:27:23 +08:00
tamakyi
0124e392c7
fix(correctness): 三处幂等缺陷、私聊首条事务化、验证码失败不再丢正文
...
四处都属于「并发/失败路径下状态不一致」，用户侧表现为「点了没反应」「发了没收到」。
1) 删除会话重复回退配额
MarkDeletedByOwner 是 check-then-act：双击时两个请求都读到 is_deleted_by_owner=false，
都执行 UPDATE、都执行一次 IncrementQuota(-1)。计数不会变负，但会白吃掉其他会话的额度，
表现为定量收集提前关闭，箱主重置计数也校准不回来。
→ 改条件更新 + RowsAffected 决定是否回退。
2) 双击产生两条重复追问
「上一条追问必须先被回复」原来只在 handler 里判断（事务外）：两个请求都能通过那次检查，
随后被 CreateIfBelowLimit 的问题行锁串行化，各自 count 都 < 3 —— 两条相同追问都建成，
吃掉 2/3 名额，箱主还收两封邮件。
→ 判定挪进事务，新增 ErrFollowUpAwaitingReply；handler 的预检查保留作为快速失败。
3) 双击置顶结果与预期相反
SetPinned(id, !question.IsPinned) 是 read-modify-write：两个请求都读到 false 都写 true，
用户点两次期望「置顶后取消」，实际仍是「置顶」。
→ 新增 SetPinnedIfCurrent(current, next)，第二次因状态已变而 0 行，语义是「只切换一次」。
4) 私聊首条三步写入无事务
建会话 → 写首条消息 → 计数是三次独立写入，第二步失败会留下 message_count=0 的空会话，
箱主列表里能点进去却什么都没有；而 BeforeCreate 已占掉一个 6 字符 token（唯一索引），
孤儿会话永久占用它。
→ 新增 CreateWithFirstMessage，三步收进一个事务。
5) 验证码失败丢正文
该分支原来走 SetErrorFlash + Redirect，而其它失败分支都是 SetError + Success 回填表单。
验证码失败恰恰是最常见的失败（token 过期、网络抖动），结果用户写好的正文整段丢失。
→ 改为同请求渲染并回填；错误文案不再透传 err.Error()（可能含上游原始信息）。
6) 5 处裸类型断言改带 ok（share.go ×3 / context.go ×1 / user/vote.go ×1），
断言失败时丢弃脏缓存并走重建，而不是 panic 掉整个请求。share.go 的 ttlCache 补 Delete。
验证：内部 DB 测试 3 项（并发删除只回退一次配额 5→4、双击只产生一条追问、
双击只切换一次置顶）；verify_round3.py 6/6（验证码失败 200+正文回填+不建提问、
私聊首条 message_count 与实际消息数一致）。
2026-10-29 16:28:34 +08:00
tamakyi
7802bb2078
fix(security): 修复安全审计的 P1/P2/P3 项，含全局复查新发现的两处越权与外跳
...
P1：
- 外链图片：markdown 渲染层只放行站内与自有 CDN 图片。配置里的
image_bucket_cdn_host 常写成 host/path，统一归一化后再比对，避免把自家图一起剥掉
- 密码：页面/提问密码最小 6 位；密码比对挪到验证码之后；页面密码失败锁定 5 次/10 分钟
- 客户端 IP：CF-Connecting-IP / EO-Client-IP 只在 TCP 对端可信（回环或 trusted_proxies）
时采信，公网对端带来的权威头一律忽略
P2/P3：
- 跳转参数收敛到 shared.SafeRedirectTarget：拒反斜杠与控制字符（url.Parse 会把 %0d%0a
解成 CRLF，伪造 Location），最后再用 path.Clean 验一次前缀
- 注册不再暴露「邮箱已注册 / 已停用」：与全新注册共用同一个成功出口，只在日志留痕
- CSP：默认 enforce，白名单由配置派生，覆盖 umami（运行时注入）、Turnstile 与
按 sentry_dsn 条件放行的 Sentry CDN
- /user 与 /_ 下发 no-store；补 X-XSS-Protection、Permissions-Policy，并把安全头前移到
静态资源中间件之前（原先静态文件拿不到 nosniff/HSTS）
- 封禁事实落库 ban_records；429 统一带 Retry-After 与本地化文案
- token 比较改常量时间；探索页页码上限；JSON 响应显式 Content-Type
全局复查补的两处：
- 私聊 SendMessage 的 POST 缺 conv.OwnerID 校验，被拉黑者可换 domain 继续发消息
- 页面密码 next 与登录 to 同源的反斜杠外跳
验收：verify_p1_fixes 4/4、verify_round2 19/19、verify_page_next 6/6、
verify_chat_owner 3/3（含变异对照）；单测与 go build ./... 全通过。
2026-10-27 12:37:40 +08:00
tamakyi
0181fc5c66
fix templates v3
2026-10-22 18:26:30 +08:00
tamakyi
b939d26ff0
fix templates v2
2026-10-22 17:49:25 +08:00
tamakyi
bd02eb7ed2
fix templates v1
2026-10-22 17:04:10 +08:00
tamakyi
4592b6ef24
fix v13
2026-10-19 01:58:00 +08:00
tamakyi
bd613a6f5a
fix v12
2026-10-19 01:11:28 +08:00
tamakyi
7a6417c33d
restrict v8
2026-10-18 23:32:38 +08:00
tamakyi
317c96ca17
restrict v7
2026-10-18 23:04:50 +08:00
tamakyi
d14d26df17
restrict v5
2026-10-18 21:59:12 +08:00
tamakyi
52f0712eda
restrict v4
2026-10-18 21:50:58 +08:00
tamakyi
efb19606a7
restrict v3
2026-10-18 21:36:03 +08:00
tamakyi
6bd90779f8
restrict v1
2026-10-18 21:14:59 +08:00
tamakyi
8e2325eda5
aliyun sensor server
2026-09-10 18:04:19 +08:00
tamakyi
e3e59e7c69
chore: baseline snapshot before moderation-strictness feature
...
Repo .git was damaged (refs/ missing, index truncated, object store near-empty).
Repaired via git init (rebuilt refs), stale index preserved as .git/index.corrupt-20260910.bak,
then full worktree committed as a rollback baseline.
2026-09-10 10:56:27 +08:00
tamakyi