6 Commits

Author	SHA1	Message	Date
Blizzard	883540bd7e	feat(auth): 微信扫码登录改为「带参二维码 + 关注/扫码事件」（登录即涨粉） ... 上一版做成了网页授权（OAuth 允许页），方向错了。改成用户要的流程： 扫码 → 弹公众号关注页 → 关注即登录，服务号顺带涨粉。 流程：PC 建票 → 后端用 access_token 调「带参数二维码」接口(scene=ticket) → 展示微信二维码图 → 用户扫码关注 → 微信推 subscribe/SCAN 事件到 /wx/mp/callback → 按 openid 找/建用户 → ticket 置 authorized → PC 轮询拿 JWT。 明文模式（消息加解密）：回调只验签名 sha1(sort(token,ts,nonce))，不做 AES。 关键实现点： - access_token 缓存进 Redis（跨实例共享，避免重复拉取互相失效）+ 进程内锁双检； - 事件同时处理 subscribe（未关注，EventKey 带 qrscene_ 前缀）与 SCAN（已关注，不带）； - 事件回调必须验签——否则任何人 POST 一个 openid 就能登录别人； - 回调无论如何回 "success"，否则微信重试并给用户弹"公众号故障"； - User.wechat_openid 用部分唯一索引（WHERE <> ''），避开存量空串互撞。 配置（appid/secret/token）后台可改、secret AES 加密入库。管理端「运维 → 登录设置」 列出还需在公众平台做的事（服务器 URL / Token 一致 / 明文模式 / IP 白名单）。 本地验证（真流程，非 mock）：验签回 echostr 与微信算法一致；模拟 subscribe 事件 → 建号 + 置票 → PC 轮询拿到 token+user → 库里确有该 openid 用户。真微信推真事件 留待部署后扫码。前端 web 登录页加「微信扫码/邮箱」双 tab，默认微信。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-21 08:58:31 +08:00
Blizzard	caa2602131	feat(web): 用户面订阅 —— 购买/续订入口 + 到期提醒 ... 账单页新增：当前订阅状态（套餐/发放节奏/已发放次数/到期倒计时）+ 可购套餐。 已有订阅时购买区标题自动变成「续订（在当前到期时间上顺延）」，与后端的顺延 语义一致，免得用户以为会新开一条。 到期倒计时 ≤7 天转琥珀、≤3 天转红：到期即失效且**没有任何扣款或续费通知**， 用户只能从这里看见，不显眼等于没有。 支付弹窗改为对「买什么」中立（PayItem：积分包 | 订阅），下单/轮询/超时/warn 处理全共用。给订阅复制一份弹窗的话，两边迟早漂移——之前修过的轮询问题就得修 两遍。 真环境验证：账单页显示真实订阅（已发放 3 次 = 首笔 + 补发 2 笔）、余额 3.0K （NULL 回填后的 2981）、套餐卡片算出「周期内共 3 次，合计 3.0K 积分」。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-20 16:33:59 +08:00
Blizzard	70b0419387	fix(payment): 支付轮询链路收口——查单节流 + 前端轮询重写 ... 后端： - 主动查单加最小间隔(5s)。此前 BillingOrderStatus 见 pending 就直连微信查单， 而前端 2.5s 轮一次 —— 单笔订单在 30min TTL 内可打出约 720 次渠道调用， 微信侧有频控，并发用户一多先被限流的是我们自己。回调才是入账主路径， 查单只是兜底，节流最坏只让在场用户多等 5s。 - 标记随订单落终态清除，并在补偿定时器每轮 prune 掉超 TTL 的残留 (用户扫码前就关弹窗的订单不会再被轮询，其标记无人回收)。 - 下单响应补 expires_at：二维码有效期由服务端 orderTTL 说了算， 前端硬编码一份迟早漂移。 前端(sundynix-web)： - orderStatus 不再丢掉 warn。服务端在「已付但金额与订单不符」时不入账、 挂起人工核对，订单一直停在 pending —— 丢掉 warn 用户就会一直等一个 永远不会来的结果。现在弹窗显式告警并给出订单号。 - setInterval → 递归 setTimeout：请求慢于间隔时 setInterval 会把请求摞起来， 对「每次可能触发渠道查单」的端点尤其糟。 - 标签页切走时暂停轮询(用户扫完码要切去微信 App)，切回前台立刻补查一次。 - 连续失败指数退避至 15s 封顶，断网时不再定频猛打。 - 二维码倒计时 + 失效遮罩，过期不再让用户扫一个必然失败的码。 - 明说「关掉也不会丢钱，到账会自动补上」——掉单补偿定时器本就兜底， 但此前 UI 没讲，用户只能守着弹窗。 - 关闭弹窗一律刷新余额：用户可能在关闭前一刻付款、状态刚落地。 测试：新增 handler 包首个测试，钉住节流与标记回收行为(-race 通过)。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-20 12:46:40 +08:00
Blizzard	efd185b779	feat(billing): 支付 P5.2 —— 微信支付 Native 渠道（扫码充值） ... wechatpay-go v0.2.21。凭据全 env 注入(WECHAT_MCHID/MCH_CERT_SERIAL/ MCH_PRIVATE_KEY/APIV3_KEY/APPID/NOTIFY_URL),缺一渠道即隐藏——半配置/假凭据 只打日志不拖垮 gateway(用假私钥实测过降级)。 - internal/payment:Native 下单出 code_url、APIv3 回调验签解密、主动查单, 三者统一收敛为 QueryResult。 - 下单 POST /billing/orders {pack_id}(≥member+审计):金额/积分按在售包服务端 锁定进订单行,不信任客户端;渠道下单失败即作废,不留付不了的 pending。 - 到账两条路汇入同一个 MarkOrderPaid 幂等闸(CAS+唯一索引双闸,同 P5.1): ①公开回调路由(验签是唯一的门;金额与订单不符不入账);②前端轮询的 GET /billing/orders/:id 在 pending 时顺路主动查单——本地/内网收不到公网 回调也能确认到账,回调只是生产更快的通道。pending 超 30 分钟置 expired。 - Web 面:在售包卡片(渠道亮才出现)→扫码弹窗(qrcode 画 code_url,二维码底色 固定纯白——暗色主题下低对比码扫不出来)→2.5s 轮询→到账 toast+刷余额。 验证:go/tsc/vitest 全绿;无凭据+假凭据两种降级 live 四连 (channels 只剩 redeem/下单 400 引导兑换码/回调 503/兑换码闭环不受影响)。 ⚠️ 真通道(prepay→扫码→回调/查单→入账)需真实商户号,未 live——用户配好 env 后用小额包实测,建议先配 ¥0.01 测试包走一单。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-17 10:39:24 +08:00
Blizzard	8e05f4b3fe	feat(billing): 支付 P5.1 —— 订单骨架 + 兑换码渠道全闭环 ... 按 PAYMENT_DESIGN.md 施工。零资质渠道先把「订单→入账→对账」的骨架跑真， 微信 Native(P5.2)进来只是多一个 adapter。 - store/payment.go:CreditPack(admin 可配包)/PaymentOrder(支付侧事实源,兑换 也写单,全部充值一个查法)/RedeemCode(SDX-XXXX-XXXX-XXXX,crypto/rand,剔除 易混字符)。三模型都不标 isTenantScoped——订单归计费租户,与活跃租户可能 分叉,插件自动注入会写错归属(RecentRuns 同款教训),显式赋值+显式过滤。 - Redeem 单事务:码 CAS 占用(unused→used 只成功一次,幂等主闸)→建已支付 订单→账本分录+物化余额。credit_ledger 加 (kind,ref) 部分唯一索引兜底 ——GrantCredits 此前对 ref 零约束,回调 at-least-once 就是重复入账事故。 - 路由:/billing/packs|orders(查,全员) + /billing/redeem(≥member+审计); admin /redeem-codes(生成/列表) + /packs(配包)。 - Web 面账单页:兑换码输入(viewer 不摆输入框,真闸在后端)+最近充值订单流。 - 测试:码形态/200 样本无撞码/参数边界;go+tsc+vitest 全绿。 live 13 项:生成→核销余额精确+100→重core 400(主闸)→DB 直插重复 ref 被唯一 索引打回(兜底闸实证)→viewer 403→balance==SUM(ledger) 不变量→审计留痕→ 浏览器 UI 兑换 100→200+订单流展示。 已知余项:admin 生成码暂只有 API(admin 页 UI 下一刀);微信 adapter=P5.2。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-17 10:18:14 +08:00
Blizzard	7c67256f87	feat(web): 薄 Web 面 sundynix-web —— 注册/组织/团队/账单自助入口 ... SaaS P3 收口第二刀(设计见 SAAS_DESIGN.md §8)。第三个产品面:desktop=用户 工作产品、admin=平台超管控制塔、web=租户客户的自助柜台——做「装桌面端之前 就要能用」的那些事,三者不合并。 - 骨架抄 admin(HashRouter+路由注册表+me()/sdx:logout 鉴权门+vite/vitest 单文件配置);UI 整目录搬 desktop 的 ui/ 组件+ink/brand 主题 token(亮暗 双主题),品牌观感与桌面端一致;api.ts 抄 desktop 的 auth/tenant/usage 段 (纯 fetch 零 Wails 依赖),成员管理/建组织打新的租户自助接口。 - 页面:登录注册(一页两态)/概览(组织+角色+余额+桌面端下载指引)/团队(名册+ 邀请+改角色+移除,写控件按角色显隐、真闸在后端)/组织(列表+自助新建+切换)/ 用量与账单(余额 hero+趋势+合计+最近消耗,数据全来自现成 /me/usage;充值 只放说明占位,支付 P5 再接,不做假入口)。 - 工程:vite :5175、launch.json 配置、make webface、ci.yml web 矩阵纳入。 - 测试:tsc 干净;vitest 3 例(fmtCredits 去尾零——测试先行抓出 1.50 毛刺; ASSIGNABLE_ROLES 不含 owner)。浏览器 live 全流程:甲(owner)登录→概览→ 团队邀请乙→乙(member)登录写控件全隐藏、名册只读,组织/用量页真数据渲染。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-16 17:47:23 +08:00