feat: add HTTP API and complete client workflows
This commit is contained in:
@@ -420,8 +420,9 @@
|
||||
### 5.8 客户端签名管理
|
||||
|
||||
- 支持新增、编辑、提交审核、上传证明材料。
|
||||
- 支持维护引流信息。
|
||||
- 支持查看通道报备状态。
|
||||
- “签名与引流信息”采用签名父级、引流信息子级的可展开工作台,提供真实后端统计、签名/应用/状态筛选、审核状态、已交资料数、驳回修改说明及新增、修改、删除操作。
|
||||
- 签名审核通过后支持维护短信中使用的网站、应用页面等引流信息;新增或修改后进入真实审核流程,客户端只展示“待提交、资料审核中、审核通过、需修改”等客户可理解的状态。
|
||||
- 客户端页面和 `/client` API 均不得暴露内部通道、通道组、路由规则、运营商报备汇总、报备任务及内部资料要求快照。动态审核字段接口只返回字段名称、类型、必填规则等客户填报所需信息;通道级报备状态仅限运营端查看。
|
||||
|
||||
### 5.9 客户端账户计费
|
||||
|
||||
@@ -457,6 +458,7 @@
|
||||
- 企业短信模板列表必须采用自适应布局,在常用桌面及平板视口下无需水平滚动即可看到编辑、删除等操作。
|
||||
- 运营端“企业模板管理”以响应式列表行展示模板、归属、内容、状态和更新时间;预览、编辑、删除操作在常用视口内始终可见,不得依赖水平滚动。
|
||||
- 运营端“企业签名管理”的移动、联通、电信报备状态必须将状态文字与通过数/总数允许分行展示;报备详情、报备状态、编辑、删除四个操作按钮在空间不足时按每行两个排列,不得将按钮文字挤成单字换行。
|
||||
- 运营端企业签名的状态颜色必须按统一业务语义展示:全部目标通道通过为绿色、部分通过为蓝色、审核中/报备中/资料待补充为橙色、审核或报备失败为红色、未提交/未报备/不适用为灰色;卡片总体色先遵循签名审核状态,再汇总真实通道报备状态,不能把“报备中”和“部分通过”混成同一种颜色。
|
||||
|
||||
### 5.12 运营端审核
|
||||
|
||||
@@ -507,7 +509,7 @@
|
||||
- 企业黑名单:企业应用级号码拦截,同一企业不同短信应用的黑名单互不影响。
|
||||
- 全局黑名单:平台维度号码拦截。
|
||||
- 敏感词管理:发送前和审核时命中提示或拦截。
|
||||
- 手机号段库:用于运营商识别和路由;列表使用服务端游标分页和服务端搜索,不查询或展示全库总条数。
|
||||
- 手机号段库:用于运营商识别和路由;号段与运营商区分规则使用真实服务端分页、搜索和总数。通用 Tab 位于页面标题下、搜索条件上;每个 Tab 只显示本类统计数字,不同时展示另一类统计。
|
||||
- 引流信息字段库:用于签名/报备资料结构化采集。
|
||||
- 企业应用级黑名单、全局黑名单、敏感词管理必须提供搜索、添加、启停/删除功能;所有操作调用真实后端 API,写入系统日志。
|
||||
- 企业黑名单必须绑定到具体短信应用,支持按企业、应用、手机号、入库原因、状态搜索;发送预览、风控和发送链路只能拦截当前应用的 active 黑名单号码,不得把同企业其他应用的黑名单串用;全局黑名单支持按手机号、原因、状态搜索;敏感词支持按词、分类/级别、状态搜索。
|
||||
@@ -1435,6 +1437,7 @@
|
||||
- 单次登录绝对时长为 12 小时,无论是否持续操作均不得自动续期;到期必须使用账号、密码和图形验证码完整登录。修改密码、禁用/删除用户、角色变化和管理员强制下线必须通过 `sessionVersion` 和 Redis 会话立即撤销现有会话。
|
||||
- 用户、权限、企业状态、应用密钥、通道配置、路由、报备状态和资金调整等敏感操作要求最近 30 分钟内验证过当前密码。超时后由后端返回 `RECENT_AUTHENTICATION_REQUIRED`,前端验证当前密码后自动重试原操作;不能只依赖前端弹窗判断。
|
||||
- 主动退出、空闲锁定、密码解锁、敏感操作再认证和会话创建均需写真实系统日志;多标签页使用浏览器消息同步锁定、解锁和退出。普通网络错误、400、403 业务拒绝或 5xx 不得被误判为自动退出。
|
||||
- 在同一浏览器已有运营端或客户端会话时,另一个入口的账号、密码、角色或验证码登录失败只属于本次登录尝试,不得清理、广播退出或跳转已有会话;只有现有会话自身的 401 失效响应才触发退出处理。
|
||||
|
||||
### 2. 用户类型和企业关联
|
||||
|
||||
@@ -1487,3 +1490,28 @@
|
||||
4. 创建批次时按每条资料所属企业应用的当前生效路由规则展开所有通道;一个签名走多个通道时,必须为每个通道创建或重置独立报备任务并生成一份该通道的 `.xlsx`。无生效路由、通道未配置字段或缺少通道必填资料时,该资料继续保留在待报备池,任务进入“资料待补充”,不得伪装为已完成。
|
||||
5. 通道“配置签名报备字段”和“配置引流信息字段”弹窗使用字段池,按资料类型分别配置。每列包含标准字段、通道导出表头、列顺序、必填、说明、列宽、文本转换、缺省值以及图片宽高;导出表头和列顺序必须严格使用通道配置,不受导入表格原始名称和顺序影响。
|
||||
6. 通道导出文件必须为 WPS/Excel 可打开的 `.xlsx`,图片直接内嵌到对应单元格区域,而不是仅写 MinIO URL 或本地路径。批次保留所选材料版本快照、通道文件、行号和通道任务关联,可从最近批次直接下载每个通道文件。
|
||||
## HTTP 客户接口第一版
|
||||
|
||||
### 管理端企业应用配置
|
||||
|
||||
- CMPP 与 HTTP 是两套可独立开通的接入能力,不再把 HTTP 作为 `interfaceType` 的互斥选项。运营端在企业应用“接口配置”中维护 HTTP 总开关,以及单条发送、短信状态查询、回执 Webhook、上行 Webhook、上行查询、客户端凭据自助管理等子能力。
|
||||
- HTTP 配置独立维护 IP/CIDR 白名单、应用级 QPS、签名时间容差、最多有效凭据数、上行保留/查询范围/分页上限、Webhook 超时和最多尝试次数、生产 HTTPS 约束、客户手工重投权限。
|
||||
- 回执和上行分别配置 `cmpp/http/both/none` 投递模式。Gateway 产生的回执或上行必须先写入现有真实短信记录,再按模式投递;HTTP 回调不得取代或伪造 Gateway、回执匹配和上行认领链路。
|
||||
- HTTP 访问密钥和 Webhook 签名密钥使用 `HTTP_API_MASTER_KEY` 派生的 AES-256-GCM 密钥加密保存。Secret 只在创建或轮换当次返回,后续运营端和客户端仅显示末四位;允许同时保留多个有效凭据以完成无停机轮换。
|
||||
|
||||
### 客户接口与安全约束
|
||||
|
||||
- 第一版提供 `POST /api/openapi/v1/sms/messages` 单条发送、`GET /api/openapi/v1/sms/messages/{messageId}` 状态查询、`GET /api/openapi/v1/sms/uplinks` 上行游标查询和 `GET /api/openapi/v1/sms/uplinks/{uplinkId}` 上行详情。
|
||||
- 身份只由 `X-App-Key` 对应凭据确定,不接受请求体中的企业或应用身份。签名原文为 `METHOD + "\n" + PATH + "\n" + X-Timestamp + "\n" + X-Nonce + "\n" + SHA256(rawBody)`,使用 Secret 执行 HMAC-SHA256。
|
||||
- 时间戳默认允许正负 5 分钟;签名成功后使用 Redis `SET NX EX` 防 nonce 重放,并按应用在 Redis 执行秒级 QPS 限制。IP 白名单与 CMPP 白名单相互独立。
|
||||
- 单发必须提供 8~128 位 `Idempotency-Key`。PostgreSQL 对 `(applicationId, idempotencyKey)` 建唯一约束并保存请求体哈希和响应快照:相同内容重放原响应,不同内容返回 409;`clientMessageId` 在应用内唯一。
|
||||
- 单发复用现有 `SendChainService`,必须经过真实企业/应用、签名、模板、风控、余额、计费、通道路由和 Redis 队列链路;接收成功返回 202,不代表运营商提交或终端到达成功。
|
||||
- 上行查询只返回已匹配或人工认领到当前应用的记录,默认最近 24 小时,单次范围和分页上限由应用配置控制;未匹配和歧义上行不得泄露给任一客户。
|
||||
- 客户错误使用 `application/problem+json` 和稳定业务码。客户 Swagger 只包含四个 `/openapi/v1` 接口,不得包含 admin、client 管理或 gateway 内部接口。
|
||||
|
||||
### HTTP Webhook 与客户端页面
|
||||
|
||||
- 状态回执和上行回调分别配置 HTTPS URL 与独立事件类型,共享该端点的签名密钥;每个事件生成唯一 `eventId`。回调请求用 `TIMESTAMP + "\n" + rawBody` 执行 HMAC-SHA256,客户必须按 `eventId` 幂等。
|
||||
- Webhook 禁止重定向,并在保存和每次投递前解析域名,拒绝环回、私网、链路本地、共享地址和元数据地址。2xx 成功;网络错误、408、429、5xx 可按立即、1 分钟、5 分钟、15 分钟、1 小时、6 小时、24 小时重试;其他 4xx 直接终结。
|
||||
- PostgreSQL 分别保存 Webhook 事件、投递状态和每次尝试摘要;客户和运营人员可查询,授权后可手工重投。首次投递与重试均由 BullMQ 执行,不得使用浏览器定时器或 localStorage 冒充。
|
||||
- 客户端“短信基础配置”新增“接口对接”,包含接口概览、访问凭据、回调配置、接口文档、调用与回调记录五个页签;企业应用卡片显示 HTTP 开通状态并跳转。客户端上行列表改为真实服务端条件查询,不再先拉全量数据后仅在浏览器过滤。
|
||||
|
||||
@@ -29,6 +29,7 @@ REPO_URL=http://175.27.255.91:3000/hectorzhao/lislgosms.git
|
||||
BRANCH=main
|
||||
PUBLIC_HTTP_PORT=12026
|
||||
API_PORT=3000
|
||||
HTTP_API_MASTER_KEY=<至少32位随机值,用于AES-256-GCM加密HTTP访问凭据和Webhook密钥>
|
||||
API_ENABLE_SEND_WORKER=true
|
||||
API_SEND_WORKER_CONCURRENCY=50
|
||||
ADMIN_SESSION_IDLE_TIMEOUT_MS=3600000
|
||||
|
||||
@@ -105,6 +105,21 @@
|
||||
- 提交后签名状态变为 pending。
|
||||
- 生成审核记录。
|
||||
|
||||
### TC-CLIENT-003A 签名与引流信息工作台及通道信息隔离
|
||||
|
||||
- 优先级:P0
|
||||
- 前置条件:真实 PostgreSQL 中存在多个审核状态的企业签名、至少一个已通过签名包含引流信息;应用的生效路由配置了通道级动态资料字段。
|
||||
- 步骤:
|
||||
1. 企业客户打开“签名与引流信息”,核对顶部全部、审核中、通过、需修改数量与真实 API/数据库。
|
||||
2. 按签名关键字、所属应用、审核状态筛选,并展开签名查看关联引流信息。
|
||||
3. 新增签名并填写动态审核资料;对可编辑签名和引流信息执行修改,对记录执行删除确认。
|
||||
4. 检查 `/client/signatures`、`/client/signatures-workspace`、`/client/applications/:id/report-fields` 响应和页面文本。
|
||||
- 预期结果:
|
||||
- 列表、统计、筛选、审核状态、资料数量、修改说明和引流信息均来自真实 NestJS API 与 PostgreSQL,刷新后保持一致。
|
||||
- 客户端只展示“待提交、资料审核中、审核通过、需修改”等客户状态;签名审核通过后才可新增引流信息,待审记录不可重复编辑。
|
||||
- 页面及客户端 API 均不包含通道 ID/编码/名称、通道组、路由、运营商报备汇总、报备任务或内部资料要求快照;动态字段仍按真实应用路由合并并由 API 校验必填值。
|
||||
- 删除操作经过确认并写入真实状态,其他企业的签名无法读取、修改或删除。
|
||||
|
||||
### TC-CLIENT-004 模板变量识别与提交审核
|
||||
|
||||
- 优先级:P0
|
||||
@@ -3389,6 +3404,7 @@ npm run verify:phase8
|
||||
| TC-AUTH-010 | 持续操作至绝对期限,将默认 12 小时在测试环境缩短验证。 | 用户活动只能刷新空闲时间,不能延长绝对期限;到期返回 `401/SESSION_ABSOLUTE_TIMEOUT`,必须重新输入账号、密码和验证码。 |
|
||||
| TC-AUTH-011 | 登录超过最近认证窗口后执行用户禁用、手工充值、通道修改、路由修改或报备状态修改。 | 后端先返回 `403/RECENT_AUTHENTICATION_REQUIRED`,输入当前密码后 30 分钟内自动重试;错误密码不执行原操作,数据库无副作用。 |
|
||||
| TC-AUTH-012 | 分别执行主动退出、修改密码、禁用、删除和角色变更,并在另一标签页继续请求。 | Redis 会话删除或 `sessionVersion` 失效;所有标签页同步退出;旧 Cookie 均返回 401;系统日志可查询创建、锁定、解锁、再认证和退出事件。 |
|
||||
| TC-AUTH-013 | 同一浏览器先登录运营端并保持一个受保护页面,再打开客户端登录页,分别提交错误账号、错误密码、错误角色和错误验证码。 | 客户端仅显示本次登录失败原因并刷新验证码;不得清除现有运营端展示会话、广播 logout 或把运营端页面跳回登录页;运营端随后请求真实受保护 API 仍成功。反向从客户端会话测试运营端错误登录结果相同。 |
|
||||
| TC-USER-ADMIN-001 | 运营端新增平台管理员,填写用户名/登录账号、邮箱或手机号、初始密码。 | 创建成功;用户无 `tenantId`;可登录运营端;写 `user.created` 日志。 |
|
||||
| TC-USER-ADMIN-002 | 运营端新增企业管理员但不选择企业。 | 返回 400;不创建用户。 |
|
||||
| TC-USER-ADMIN-003 | 运营端新增企业管理员并选择企业。 | 创建成功;用户关联企业;可登录客户端;客户端数据按该企业隔离。 |
|
||||
@@ -3407,6 +3423,7 @@ npm run verify:phase8
|
||||
| TC-UI-TEMPLATE-RESPONSIVE-001 | 在 1024px、1366px 和宽屏视口打开企业短信模板页。 | 模板卡片自适应换列,页面不出现水平滚动,每张卡片的编辑和删除按钮直接可见。 |
|
||||
| TC-ADMIN-ENTERPRISE-TEMPLATE-RESPONSIVE-001 | 在 1024px、1366px 和宽屏视口打开运营端“企业模板管理”,查看长企业名、长模板内容和包含多变量的真实记录。 | 列表行按视口自适应重排,无水平滚动;预览、编辑、删除始终可见且可操作,内容摘要不撑破容器。 |
|
||||
| TC-ADMIN-ENTERPRISE-SIGNATURE-LAYOUT-001 | 在运营端“企业签名管理”打开移动/联通/电信显示“未报备(0/2)”的真实签名,分别使用 1024px 和 1366px 视口。 | 状态标签和数量可分行但各自保持完整;四个操作按钮按两列两行排列,文字不被挤成单字换行,卡片不产生水平滚动。 |
|
||||
| TC-ADMIN-ENTERPRISE-SIGNATURE-COLOR-001 | 使用真实签名和通道任务分别覆盖草稿、待审核、审核驳回、未报备、报备中、资料待补充、部分通过、全部通过和报备失败。 | 总体色条依次遵循审核优先、报备汇总次优先;全部通过为绿、部分通过为蓝、处理中或待补资料为橙、失败为红、未开始或不适用为灰。三网标签使用同一语义,“报备中”不得显示成“部分通过”的蓝色。 |
|
||||
| TC-ADMIN-ENTERPRISE-SIGNATURE-SELECT-001 | 在运营端打开“添加签名”,展开企业下拉并输入部分名称,选择企业后再展开企业应用;分别使用常规高度和 600px 高视口。 | 两个下拉均通过浮层完整显示在弹窗和底部操作栏之上,可搜索、滚动并选择真实 API 选项;空间不足时自动向上展开,列表不被裁剪。 |
|
||||
| TC-ADMIN-REPORT-FIELD-CODE-001 | 在报备字段库分别提交 `License2026`、`license_code`、中文和空白代码,并直接调用真实新增 API 复验。 | 只有 `License2026` 写入 PostgreSQL;前端阻止非法值,API 同样返回 400,不依赖前端校验。 |
|
||||
| TC-ADMIN-CHANNEL-REPORT-SIGNATURE-001 | 打开包含数据库签名 `【安徽航天信息】` 的通道报备详情及签名详情弹窗。 | 两处均只显示单层 `【安徽航天信息】`,不出现重复中括号。 |
|
||||
@@ -3415,7 +3432,7 @@ npm run verify:phase8
|
||||
| TC-MOCK-CLEAN-005 | 运营端短信审核通过、批量通过、驳回风控审核任务。 | 调用 `admin/risk-review/tasks` 真实接口;通过必须弹窗确认;状态刷新后仍持久化;不再显示固定手机号样例。 |
|
||||
| TC-MOCK-CLEAN-006 | 运营端短信记录按手机号、状态、日期和内容查询,打开详情。 | 数据来自 `sms_message_records`;详情展示真实 messageId、状态、失败原因;无数据时为空态。 |
|
||||
| TC-MOCK-CLEAN-007 | 访问明确标注待开发的彩信菜单。 | 可以显示待开发/空态;不得作为第一版短信真实功能通过依据。 |
|
||||
| TC-PHONE-SEGMENT-001 | 生产库存在 50 万级手机号段时打开手机号段库,连续点击下一页、上一页,并按号段、省份、城市或运营商搜索。 | API 使用 `prefix` 游标分页并返回 `hasMore/nextCursor`;页面数据来自真实数据库,可稳定前后翻页和搜索;接口不执行全表总数统计,页面不展示号段总条数。 |
|
||||
| TC-PHONE-SEGMENT-001 | 生产库存在 50 万级手机号段时打开手机号段库,连续点击下一页、上一页,并按号段、省份、城市或运营商搜索。 | 页面数据来自真实数据库,可按服务端 `total/page/pageSize` 稳定分页和搜索;Tab 位于标题下、搜索条件上。手机号段 Tab 只显示号段总数,运营商区分规则 Tab 只显示规则总数,切换时不同时展示两个统计。 |
|
||||
|
||||
### 17.11 下游投递 ACK 与应用级重试策略
|
||||
|
||||
@@ -3453,3 +3470,20 @@ npm run verify:phase8
|
||||
| TC-GW-RATE-002 | 超过通道 TPS 后观察 Redis Stream consumer group,并在存在等待消息时重启 Gateway。 | 超流速消息保留在 Stream pending,不直接失败;重启后通过 PEL/XAUTOCLAIM 恢复并继续按通道 TPS 排队提交,不丢失、不重复 ACK。 |
|
||||
| TC-GW-RATE-003 | 启动两个共享同一 Redis 的 Gateway 消费实例,同时向同一通道发送,再向两个不同通道发送。 | 同一通道的两个实例共享 Redis 限速额度,总 TPS 不叠加;不同通道使用独立 key,不被合并成平台总 TPS。 |
|
||||
| TC-GW-RATE-004 | 在存在 active 上游通道时按生产脚本顺序重启 Gateway 和 API,随后检查 Gateway 日志、连接状态与 Redis。 | Gateway 先启动,API 随后重新下发全部 active 通道连接命令;Gateway 内存连接池恢复,数据库状态反映本次真实连接结果,并生成 `rate:gateway:channel:config:<channelId>`,不沿用重启前的假 connected。 |
|
||||
|
||||
### 17.14 HTTP 客户接口、上行查询与 Webhook
|
||||
|
||||
| 用例编号 | 操作 | 预期结果 |
|
||||
| --- | --- | --- |
|
||||
| TC-HTTP-CONFIG-001 | 运营端编辑企业应用,独立开关 CMPP 与 HTTP,并配置发送/查询/回调子能力、独立 IP 白名单、QPS、投递模式和 Webhook 策略,保存后刷新。 | 配置写入 `SmsApplicationHttpConfig` 和 HTTP 白名单表;CMPP 原配置不丢失;刷新一致;关闭某项能力后对应 OpenAPI 返回稳定 403 业务码。 |
|
||||
| TC-HTTP-AUTH-001 | 使用正确 Access Key/Secret 按原始请求体签名,再分别修改 path、body、timestamp、nonce、来源 IP 和签名。 | 正确请求通过;篡改项返回 `application/problem+json`;过期时间、重复 nonce、白名单外 IP 和错误签名被拒绝;错误签名不得提前占用 nonce。 |
|
||||
| TC-HTTP-AUTH-002 | 同一应用一秒内并发调用超过配置 QPS,再在下一秒继续调用。 | Redis 应用级额度不被多个凭据放大;超额返回 429,下一秒恢复;不依赖单进程内存计数。 |
|
||||
| TC-HTTP-CREDENTIAL-001 | 客户创建第一把凭据、保存 Secret,再创建第二把完成切换并吊销第一把;刷新页面和查看数据库。 | Secret 仅创建当次可见,数据库为 AES-256-GCM 密文;列表只显示末四位;两把凭据轮换期可并存,吊销后旧凭据立即返回 401。 |
|
||||
| TC-HTTP-SEND-001 | 调用单条发送接口,使用真实已审核签名/模板、余额和通道路由。 | 返回 202 和平台 messageId;真实创建 API 来源批次与短信记录,执行风控、冻结/计费并进入 Redis/BullMQ/Gateway 链路;不得使用静态数组或直接伪造 delivered。 |
|
||||
| TC-HTTP-IDEMPOTENCY-001 | 并发使用相同 `Idempotency-Key` 和相同 body 调用,再用相同 key 改变 body;另重复 clientMessageId。 | 只创建一条真实短信;完成后同内容重放原响应,处理中返回 409 processing;不同 body 返回 409 conflict;应用内重复 clientMessageId 被拒绝。 |
|
||||
| TC-HTTP-QUERY-001 | 用本应用凭据按 messageId/clientMessageId 查询本应用和其他应用短信。 | 只返回当前应用短信状态、提交/回执时间和失败信息;其他应用记录统一 404,不泄露租户数据。 |
|
||||
| TC-HTTP-UPLINK-001 | 查询默认 24 小时上行,组合手机号、接入号、关键词、时间和 cursor;构造匹配、歧义和未匹配记录。 | 只返回已匹配或人工认领到当前应用的记录;按 `(receivedAt,id)` 稳定倒序游标分页;超查询范围和非法 cursor 返回 400;歧义/未匹配不泄露。 |
|
||||
| TC-HTTP-WEBHOOK-001 | 配置 HTTP 或 both 投递,分别触发终端回执、平台失败回执、自动匹配上行和人工认领上行。 | 事件只在真实记录落库后产生;HTTP 模式不创建 CMPP 投递,both 同时创建两条独立链路;eventId 唯一,payload 包含可关联 messageId/uplinkId。 |
|
||||
| TC-HTTP-WEBHOOK-002 | 回调依次返回 500、429、408、400、302 和 200,并模拟超时。 | 500/429/408/网络错误按既定退避重试,400 和重定向终结,2xx 成功;每次尝试、状态码、耗时和截断响应写 PostgreSQL,可授权手工重投。 |
|
||||
| TC-HTTP-WEBHOOK-003 | 保存指向 localhost、RFC1918、链路本地、共享地址、云元数据 IP、会解析到私网的域名和发生 DNS 重绑定的 URL。 | 保存或投递前被 SSRF 校验拒绝;不跟随重定向;生产 HTTPS 约束开启时 HTTP URL 被拒绝。 |
|
||||
| TC-HTTP-CLIENT-001 | 客户端打开“接口对接”五个页签,切换应用、创建凭据、配置回调、查看文档与日志;API 断开后重试。 | 所有状态来自真实 API/PostgreSQL/Redis;应用卡片显示 HTTP 状态;API 失败展示错误,不使用 localStorage 或前端静态数据伪造成功。 |
|
||||
|
||||
@@ -1,6 +1,14 @@
|
||||
# 第一版系统化测试进度
|
||||
|
||||
## 2026-07-15 短信模板签名自动填充与真实校验(未提交、未部署)
|
||||
## 2026-07-16 客户端签名与引流信息页面重做(已验收,待发布)
|
||||
|
||||
- 客户端“签名与引流信息”按运营端信息结构重做为签名父级、引流信息子级的可展开工作台,增加真实后端状态统计、关键字/应用/状态筛选、已交资料数、修改说明、新增/修改/删除确认;客户端文案不再出现通道和内部报备概念。
|
||||
- 新增客户端专用安全视图和工作台 API。NestJS 查询仅选择客户需要的签名、应用、材料和引流字段;动态资料字段移除通道来源,签名响应移除通道、路由、运营商汇总、报备任务和内部要求快照,避免只靠前端隐藏造成泄露。
|
||||
- 客户端签名更新补充企业归属校验并重新进入审核;签名列表的顶部统计由 PostgreSQL 状态分组通过真实 API 返回,不使用 mock、localStorage 或前端临时统计冒充。
|
||||
- Prisma validate/generate/migrate status 通过,本地 PostgreSQL 共 52 条 migration 且无待执行项;SmsConfig 定向 1 suite/37 项、API 全量 20 suites/209 项、API build、前端 build、Gateway `go test ./...` 和 `git diff --check` 均通过。Jest 延续既有 open-handle 提示,使用同一全量用例加 `--forceExit` 复核退出码为 0;前端仅有既有 Vite chunk size warning。
|
||||
- 应用内浏览器可加载最新本地构建,但目标路由因无现成客户端登录态跳转至真实图形验证码登录页;Chrome 也没有可复用的平台登录页。本轮未绕过验证码,因此没有把登录页误记为目标页面视觉通过,登录后的展开、筛选和弹窗交互仍建议补一次可见复测。
|
||||
|
||||
## 2026-07-15 短信模板签名自动填充与真实校验(已验收,待发布)
|
||||
|
||||
- 客户端和运营端短信模板表单将签名改为必选;选择签名时自动在模板内容开头填入规范 `【签名】`,切换签名只替换原前缀并保留正文,清空选择时移除自动前缀。
|
||||
- 两套内容输入框均明确提示“模板内容必须以所选签名开头”,字符数、变量识别和计费条数继续基于包含签名的完整内容计算。
|
||||
@@ -1916,7 +1924,7 @@ git diff --check
|
||||
- 发布快照本地与服务器 SHA-256 均为 `489d6c969252403689dfdcca15b87e4f5a93b65187551fa6650451527366942e`。生产 `.deployed-commit=a7a4e8d9f6aba00b8137e5b70c59bdef67ed3b57`,47 条 migration 全部齐全;`cmpp-api`、`cmpp-gateway`、MinIO、Nginx、PostgreSQL、Redis 均为 active,`12026/17890/8090/3000/9000` 正常监听,API/Gateway health、Redis PONG、PostgreSQL readiness 和外部首页/运营端/API HTTP 均通过,部署后 API/Gateway 无 error 级日志。
|
||||
- 生产浏览器确认登录页加载成功且标题为“聆界短信管理平台”。服务器凭据文件对存量管理员仅记录 `password=unchanged`,不是可用明文密码,因此未擅自重置生产密码;通用 Select 的企业搜索、企业与应用联动、弹窗越界和普通筛选区 Portal 交互已在部署前通过本地真实 NestJS API、PostgreSQL 数据和生产同构建验证,未使用 mock、localStorage 或静态数组。
|
||||
|
||||
## 2026-07-15 签名与引流资料批量导入及统一通道报备(未提交)
|
||||
## 2026-07-15 签名与引流资料批量导入及统一通道报备(已验收,待发布)
|
||||
|
||||
- 新增真实待报备资料工作台:WPS 表格另存 `.xlsx` 后由 NestJS + ExcelJS 解析多行表头、文本和内嵌图片,原文件及图片走 MinIO,导入批次、可复用映射方案、材料版本和待报备状态走 Prisma/PostgreSQL;导入只更新资料池,不自动生成通道任务。
|
||||
- 新增统一报备批次:运营勾选新建/修改的签名与引流信息后,按企业应用当前生效路由展开全部通道,每通道生成一份内嵌图片的 `.xlsx`,并关联批次材料版本快照、文件行号和真实通道报备任务。无路由、未配置通道字段或缺必填资料不会清除待报备标记。
|
||||
@@ -1924,7 +1932,7 @@ git diff --check
|
||||
- Prisma migrations `20260715190000_add_report_material_import_export_workflow`、`20260715193000_scope_channel_report_fields_by_type`、`20260715194000_initialize_existing_report_material_pending` 已在本地真实 PostgreSQL 成功应用,50 条 migration status 齐全;字段范围迁移将旧 `both` 配置拆成签名/引流两份,并允许同一标准字段在两类中使用不同表头和顺序;初始化迁移不把上线前所有历史签名误认成本次新建/修改资料。Prisma validate/generate、API 全量 19 suites/198 项、API build、前端 build、Gateway 全量 Go 测试、根目录与 API 生产依赖 audit、`git diff --check` 均通过;audit 为 0 漏洞,前端仅有既有 Vite chunk size warning,Jest 仍需 `--forceExit` 退出既有异步句柄。
|
||||
- 应用内浏览器使用本地真实 NestJS API/PostgreSQL 会话验证 `/admin/report-materials`:真实待报备签名加载成功,勾选后“统一生成通道报备”由禁用变为可用;导入弹窗展示企业/应用、映射方案、表头行和 XLSX 文件控件。进入真实通道报备详情后,签名字段配置弹窗按字段池/导出字段双栏渲染,页面和两次交互均无 console error/warn、无框架错误覆盖。未点击统一生成、未上传客户文件、未写入烟测业务数据。
|
||||
|
||||
## 2026-07-15 通道 TPS 配置口径清理(未提交)
|
||||
## 2026-07-15 通道 TPS 配置口径清理(已验收,待发布)
|
||||
|
||||
- 明确 `SmsChannel.rateLimitPerSecond` 是单个物理通道的 TPS 上限,不是平台总流速;Redis 限速键包含通道 ID,不同通道独立计数。
|
||||
- 同一物理通道即使被多个通道组引用,也共享通道自身的同一限速桶,不按通道组重复获得额度。
|
||||
@@ -1942,3 +1950,18 @@ git diff --check
|
||||
- 启动恢复修正提交 `85ff0376` 已 push 并完成最终运行时发布;发布前第二次备份至 `/opt/cmpp-platform/backups/releases/20260715-183017`,数据库、源码、环境文件 SHA-256 分别为 `8d632d63db1afcad37889b445e3989819c15053d544f3a63239dca20cd0baecd`、`5ffc421046f436d5f8ed8178c7a884c4e476567826740d469f4560360304744d`、`87ab2efd509b39849b0ee22ead1b4cf0568fba4ab8525c59b5c78da51c73bc86`;最终运行发布包本地/服务器 SHA-256 均为 `930ac2a24bf6c1ee24cdfb2f90dff26d89bf7e1f9d84425aa800e66aa8ef4b9a`。
|
||||
- 生产 51 条 migration 全部齐全;`cmpp-api`、`cmpp-gateway`、MinIO、Nginx、PostgreSQL 和 Redis 正常,`12026/17890/8090/3000/9000` 监听,API/Gateway health、Redis PONG、外部首页和运营入口均通过,受保护异常列表无会话返回 401,Redis Stream consumer group pending=0、lag=0,部署后近期 API/Gateway 无 error 级日志。
|
||||
- 两个 active 上游通道在本次 Gateway/API 启动后均产生新的 `cmpp_connection.connect_requested` 与 `cmpp_connection.connected` 审计,currentConnections=1;Redis 生成 `rate:gateway:channel:config:<channelId>` 两个独立 key,值均为各自真实配置 100,证明 Gateway 内存连接池与最终 TPS 上限已由当前进程恢复。生产前端资源包含“Gateway提交异常”;应用内浏览器访问新路由按真实鉴权跳转运营端登录,标题、DOM 正常且 console 无 error/warn,未绕过图形验证码。
|
||||
|
||||
## 2026-07-16 签名颜色、手机号段布局与跨入口登录失败隔离(已验收,待发布)
|
||||
|
||||
- 企业签名卡片建立审核优先、报备汇总次优先的统一颜色规则:全部目标通道通过为绿色、部分通过为蓝色、待审核/报备中/资料待补充为橙色、审核或报备失败为红色、草稿/未报备/不适用为灰色。三网标签将“报备中”从蓝色改为橙色,与“部分通过”明确区分;总体色条增加可访问状态说明。
|
||||
- 手机号段库通用 Tab 移到页面标题下、搜索条件上;手机号段和运营商区分规则的统计卡分别放入各自 Tab,只展示当前类型的真实服务端总数。搜索、分页、新增和删除仍调用原 NestJS/Prisma API。
|
||||
- 修复同浏览器跨入口错误登录误踢已有会话:`/admin/auth/login`、`/client/auth/login` 的 401 仅作为本次凭据失败返回,不再进入通用“现有会话失效”分支,不清理展示会话、不广播 logout、不跳转原入口。受保护 API 自身返回的 401 仍按 Redis 会话失效、锁定或撤销规则处理。
|
||||
- 本地 PostgreSQL、Redis、正式构建的 NestJS API 和 Vite 生产构建已启动;API 19 suites、200 项全部通过,API build、前端 TypeScript/Vite build 和 `git diff --check` 通过,前端仅有既有 chunk size warning。应用内浏览器确认本地真实 API 登录页、标题、DOM 和验证码请求正常;因未获本轮图形验证码代填授权,未绕过 HttpOnly Cookie 或 localStorage 进入受保护页面,签名颜色、Tab 切换及“已有管理端会话 + 客户端错误密码”可视交互待授权后补测。
|
||||
## 2026-07-16 HTTP 单条发送、回执/上行回调与上行查询(已验收,待发布)
|
||||
|
||||
- 已新增独立 HTTP 接入数据模型与 migration `20260716110000_add_http_open_api`:应用能力配置、独立 IP 白名单、AES-256-GCM 凭据、数据库幂等请求、Webhook 端点/事件/投递/尝试记录,以及应用内唯一 `clientMessageId`。
|
||||
- 已实现 HMAC-SHA256 机器鉴权、Redis nonce 防重放和应用级 QPS、单条发送、短信状态查询、上行游标查询/详情。单发复用真实 `SendChainService` 的模板、风控、余额、计费和 Redis 入队链路;相同幂等键同内容重放、不同内容冲突。
|
||||
- 已将现有 Gateway 回执和上行落库后投递扩展为 `cmpp/http/both/none` 分流,HTTP Webhook 使用 BullMQ、事件 ID、签名、超时、尝试记录和退避重试;保存与投递前执行 HTTPS/SSRF 校验且不跟随重定向。
|
||||
- 运营端企业应用编辑页已将 CMPP 和 HTTP 改为独立开关,并增加 HTTP 子能力、白名单、QPS、凭据数、投递模式和回调策略配置。客户端新增“接口对接”五个页签,企业应用卡片显示 HTTP 状态;上行短信页改为 NestJS/Prisma 服务端条件查询。
|
||||
- 本地真实 PostgreSQL、Redis、MinIO 已启动,migration 成功应用,52 条 migration 全部齐全。临时企业应用通过真实 API 完成 HMAC/时间戳/IP、错误签名、签名后 nonce 防重放、单发业务拒绝、失败幂等重放和上行查询验收:错误签名 401 且不占 nonce,正确签名后同 nonce 重放 401,上行空集合 200;无审核签名的单发首次及相同幂等键重放均为 422,数据库未产生批次、短信、Submit 或回执,因此未向验收手机号发送。临时数据已清理。
|
||||
- API 全量 20 suites、211 项通过,Prisma validate/migrate status、API build、前端 TypeScript/生产 build、Gateway 全量 Go 测试和 `git diff --check` 通过;前端仅有既有 chunk size warning。Browser 插件不可用,使用工作区 Playwright fallback:真实图形验证码登录客户端和运营端,客户端五个页签、真实凭据/请求日志、运营 HTTP 开关及能力字段均渲染并可交互;桌面 DOM 非空、无框架覆盖、console 无 error/warn。移动端仍受既有 AppShell 侧栏布局影响,本轮未扩展修改全局响应式框架。
|
||||
|
||||
Reference in New Issue
Block a user