fix: validate signatures and restore report metrics
This commit is contained in:
hectorzhao
@@ -129,7 +129,7 @@
|
||||
|
||||
### 4.3 签名与引流信息
|
||||
|
||||
1. 客户端和运营端新增、编辑短信签名时，签名名称必须填写完整中文黑括号格式，例如 `【某某科技】`；缺少括号、英文方括号、重复括号、空括号或括号外附加文本均不得提交。NestJS API 必须执行同样校验并以完整格式写入 PostgreSQL，不能只依赖前端按钮状态。
|
||||
1. 客户端和运营端新增、编辑短信签名时，签名名称必须填写完整中文黑括号格式，例如 `【某某科技】`；输入过程中禁止录入普通空格、换行、制表符、不换行空格、零宽字符、BOM、变体选择符等空白或不可见字符，非法按键/粘贴不得进入受控输入值并需立即给出错误提示。缺少括号、英文方括号、重复括号、空括号或括号外附加文本均不得提交。NestJS API 必须执行同样的字符与格式校验并以完整格式写入 PostgreSQL，不能只依赖前端按钮状态。
|
||||
2. 运营端企业签名管理查看签名资料。
|
||||
3. 签名需完成企业内部审核和通道报备，状态包括草稿、待审核、已通过、已驳回、报备中、报备通过、报备失败。
|
||||
4. 已通过且报备通过的签名才允许发送。
|
||||
@@ -488,6 +488,7 @@
|
||||
- 支持查看通道成功率、未知率、失败率、累计发送量。
|
||||
- 通道列表的通道成本以“分”为单位展示并保留两位小数，例如 `3.00 分`；展示格式不改变 PostgreSQL 中的真实成本单价及计费快照。
|
||||
- 支持进入通道报备详情。
|
||||
- 通道报备详情必须按签名任务和引流信息任务展示真实“提交报备时间、报备成功时间、上次发送成功时间、今日发送”数据。“今日发送”至少拆分成功、未知、回执失败、提交失败四项并同时显示数量和比例；提交被拒绝或超时单独计入提交失败，不得混入已接受短信的回执失败率。签名任务汇总该签名在当前通道下的全部引流信息，具体引流任务只统计自身；上次发送成功时间取同一统计范围内最近一条最终成功短信，不得使用报备更新时间或静态演示值替代。
|
||||
- 通道报备详情页中，签名下的引流信息默认收起，用户点击后展开；展开/收起只影响页面展示，不改变报备数据。
|
||||
- 通道列表状态区域展示“连接日志”入口；点击后弹窗展示真实连接日志，包括连接请求、连接成功、断开、心跳、重连、异常等事件，日志来源于 Gateway 回写或 OperationLog。通道连接状态、连接数和最近错误必须来自 Gateway 真实上游连接池回写，不能以一次性探测拨号成功代替长连接在线状态。
|
||||
- 通道操作按钮应保持一致的两列布局，报备详情、编辑、复制、发送测试、启停、删除等操作文案清晰。
|
||||
|
||||
@@ -120,6 +120,20 @@
|
||||
- 合法名称以完整格式写入PostgreSQL；新增、编辑和所有展示位置均为`【测试签名】`。
|
||||
- 模板与发送预览只包含一层签名，不出现`【【测试签名】】`。
|
||||
|
||||
### TC-CLIENT-003C 签名空白与不可见字符前后端强制校验
|
||||
|
||||
- 优先级：P0
|
||||
- 前置条件：存在可创建、编辑签名的企业和应用。
|
||||
- 步骤：
|
||||
1. 分别在客户端和运营端新增、编辑签名，尝试键入或粘贴包含普通空格、换行、制表符、不换行空格、零宽空格、BOM和变体选择符的名称。
|
||||
2. 观察受控输入框、错误提示和提交按钮。
|
||||
3. 绕过页面直接调用真实新增、编辑API提交相同非法名称。
|
||||
4. 输入不含空白或不可见字符的合法名称`【测试签名】`并保存。
|
||||
- 预期结果：
|
||||
- 非法字符不进入客户端或运营端受控输入值，页面立即提示且不能提交；已有合法输入不因一次非法粘贴被覆盖。
|
||||
- 直接调用API返回400及可行动错误，不写入或更新`SmsSignature`，不能通过前端绕过。
|
||||
- 合法名称可正常保存，刷新后仍来自真实PostgreSQL记录。
|
||||
|
||||
### TC-CLIENT-003A 签名与引流信息工作台及通道信息隔离
|
||||
|
||||
- 优先级：P0
|
||||
@@ -3907,3 +3921,12 @@ npm run verify:phase8
|
||||
| TC-BILLING-ATOMIC-005 | 同一企业同时发生扣费、退款和充值 | 账户级事务锁串行化余额变更，使用数据库原子增量；每条流水`balanceAfter`连续且最终余额与流水一致 |
|
||||
| TC-DOWNSTREAM-IDEM-006 | 同一短信终态被重复处理，企业同时启用CMPP和HTTP | CMPP只有一条`CmppDownstreamDelivery`且只发送一次；HTTP只有一个稳定事件和一条端点投递 |
|
||||
| TC-MIGRATION-IDEM-007 | 在含历史重复最终回执的预生产数据上执行migration | 历史行全部保留；每个短信只给最早一条历史回执设置唯一键，其余保持空键；新数据开始强制唯一 |
|
||||
|
||||
## 2026-07-27 通道报备发送统计用例
|
||||
|
||||
| 用例编号 | 场景 | 预期结果 |
|
||||
|---|---|---|
|
||||
| TC-CHANNEL-REPORT-STATS-001 | 当前通道同一签名今日存在已接受成功、已接受未知、已接受失败、提交拒绝和提交超时记录 | 签名任务的“今日发送”展示四类真实数量与比例；提交拒绝/超时只计入提交失败，成功/未知/回执失败比例只以已接受数量为分母 |
|
||||
| TC-CHANNEL-REPORT-STATS-002 | 同一签名有直接短信和多个引流信息，展开具体引流任务 | 签名任务汇总当前通道下该签名全部发送；具体引流任务仅统计自身，不串入同签名其他引流或直接短信 |
|
||||
| TC-CHANNEL-REPORT-STATS-003 | 当前统计范围有历史成功短信但今日无成功短信 | “上次发送成功时间”显示该范围最近一次最终成功时间，不以报备时间、最后更新时间或页面当前时间代替 |
|
||||
| TC-CHANNEL-REPORT-STATS-004 | 报备任务先提交、后由报备记录变为通过 | 列表和详情分别显示真实提交报备时间、最近一次报备成功时间、上次发送成功时间和今日统计；刷新后数据保持一致 |
|
||||
|
||||
@@ -2542,3 +2542,20 @@ git diff --check
|
||||
- 功能提交`e0f6eed0d40e21fb06166e28dd54fefa7d0f09b0`已推送并由精确Git快照发布；快照585个条目、1741824字节，本地与服务器SHA-256均为`99ed2d4b86f91b09a87baca027441aa63bec4b0ccefae3a04be5c63d80878e3f`。部署前数据库备份为`/opt/cmpp-deploy-backups/cmpp-20260726-223344.sql`，旧运行目录保留为`/opt/cmpp-platform.previous-20260726-223344`。
|
||||
- 标准部署脚本成功应用`20260726223000_prevent_duplicate_retry_side_effects`，预发布73条migration齐全；三个目标字段、唯一索引及补发自关联外键均已落库，`.deployed-commit=e0f6eed0d40e21fb06166e28dd54fefa7d0f09b0`。API、Gateway、Nginx、PostgreSQL、MinIO均active，Redis`PONG`；`12026/17890/8090/3000/6379/5432/9000`监听，内外健康页、运营端和客户端入口HTTP 200，公网CMPP 17890可连接，发布后API/Gateway无error级日志。
|
||||
- 四个启用通道均为`connected/currentConnections=1/desiredConnections=1`；Redis提交流消费者1、`pending=0`、`lag=0`。事故短信只读复核仍为4条提交尝试、12条供应商回执、3条下游投递和3条`refunded`账务流水，证明发布未删除、重写或自动冲正历史证据；本轮未发送任何真实测试短信。
|
||||
|
||||
## 2026-07-27 HTTP环境前端随机ID兼容修复（发布前）
|
||||
|
||||
- 预发布运营端删除签名在发起删除预检前调用`crypto.randomUUID()`；公网入口为裸HTTP IP，浏览器非安全上下文中该方法不可用，导致点击后抛出`TypeError`且后端未收到删除请求。
|
||||
- 新增统一随机ID工具：安全上下文优先使用原生`randomUUID()`，HTTP等环境回退到`crypto.getRandomValues()`生成符合版本位和变体位要求的UUID v4；极旧环境无Web Crypto时保留随机字节兼容兜底。
|
||||
- 删除签名/模板/通道、签名和模板审核通过、人工充值、报备批次生成统一改用兼容工具；企业应用密码随机生成也复用随机字节实现，避免同类问题从其他入口再次出现。
|
||||
- Node.js v24.14.0下前端TypeScript检查、Vite生产构建及`git diff --check`通过；无`randomUUID()`和无Web Crypto两种模拟环境均生成格式正确的UUID v4，`getRandomValues()`回退同时生成16位十六进制应用密码。构建仅保留既有约1.95MB单chunk提示。
|
||||
- 此修改已纳入用户授权的本轮统一提交、推送和预生产发布范围；工作区原有构建缓存、`outputs/`及空文件`=`继续作为非代码临时产物隔离。
|
||||
|
||||
## 2026-07-27 签名不可见字符校验与通道报备真实统计（发布前）
|
||||
|
||||
- 客户端与运营端签名新增/编辑统一禁止普通空格、Unicode空白、控制字符和默认不可见字符；非法键入或粘贴不覆盖已有受控输入，并即时显示错误。NestJS新增、编辑接口复用相同后端校验，防止绕过页面写入非法签名。
|
||||
- 通道报备详情恢复设计基线的“提交报备时间、报备成功时间、上次发送成功时间、今日发送”列；报备成功时间取真实通过记录，上次成功时间取当前通道与签名/引流范围内最近一条最终成功短信。
|
||||
- 今日发送统计由PostgreSQL真实提交记录、分片审计和供应商回执聚合，拆分成功、未知、回执失败和提交失败。提交拒绝/超时不混入已接受短信的回执失败率；签名任务汇总签名全部引流范围，具体引流任务严格隔离到自身。
|
||||
- Node.js v24.14.0定向验证通过：通道与短信配置2 suites / 103 tests；本机临时Redis就绪后API全量26 suites / 353 tests通过，测试结束即停止临时Redis。Prisma schema校验、API TypeScript build、前端TypeScript/Vite生产构建、Gateway Go全量测试/vet和依赖安全门禁通过；前端仅保留既有约1.96MB单chunk提示。
|
||||
- 预发布PostgreSQL按新口径只读执行聚合成功：当前报备任务范围覆盖512条通道提交尝试，其中北京时间今日324条、提交失败1条、最终成功169条，最近成功时间为`2026-07-27 11:18:39.04 UTC`；查询未写入或改写业务数据。提交、推送及预生产部署结果以本轮交付回执为准。
|
||||
- 用户明确授权将工作区所有有效代码一并发布；`api/tsconfig.build.tsbuildinfo`、`tsconfig.tsbuildinfo`、`outputs/`及空文件`=`属于既有构建/临时产物，不纳入源码提交。
|
||||
|
||||
Reference in New Issue
Block a user