fix: negotiate downstream cmpp protocol versions

2026-07-11 11:00:42 +08:00
parent a4d42cf702
commit bb4992f0f9
8 changed files with 276 additions and 83 deletions
@@ -210,11 +210,11 @@
 #### 4.8.2 下游客户 CMPP 接入能力

 1. Gateway 必须监听生产 CMPP 端口 `17890`，作为平台侧 CMPP Server 接收企业客户系统连接；该端口不是 HTTP 健康检查或控制接口。
-2. Gateway 必须按企业应用生成的 CMPP 接入参数校验客户 connect/login，包括客户侧企业代码、账号、密码、CMPP 版本、源 IP 白名单、短信接口开关、应用状态、企业状态、连接数上限；客户侧企业代码必须来自 `SmsApplication.cmppEnterpriseCode`，且 `interfaceEnabled=false` 时必须拒绝鉴权和后续 submit。
+2. Gateway 必须按企业应用生成的 CMPP 接入参数校验客户 connect/login，包括客户侧企业代码、账号、密码、CMPP 版本、源 IP 白名单、短信接口开关、应用状态、企业状态、连接数上限；客户侧企业代码必须来自 `SmsApplication.cmppEnterpriseCode`，且 `interfaceEnabled=false` 时必须拒绝鉴权和后续 submit。Gateway 必须根据 CONNECT `Version` 为每条 TCP 连接独立协商 CMPP2.0/2.1/3.0 解包与响应类型，不得用固定 CMPP3.0 结构解析 CMPP2.0 Submit。
 3. 客户端应用的 IP 白名单必须对 CMPP 下游连接生效；未命中白名单、应用停用、企业停用、密码错误、超过连接数上限时必须拒绝连接并记录系统日志。
 4. Gateway 必须维护应用级下游连接状态，回写 applicationId、tenantId、connectionId、currentConnections、desiredConnections、lastHeartbeatAt、lastError，运营端企业应用列表和连接详情必须来自这些真实状态。
 5. Gateway 必须实现下游 ActiveTest、Terminate、异常断开处理；断开后连接数和状态必须及时回写。
-6. Gateway 必须处理客户提交的 CMPP Submit，将手机号、内容、源地址、企业应用、客户消息序号等转换为平台发送请求。
+6. Gateway 必须处理客户提交的 CMPP Submit，将手机号、内容、源地址、企业应用、客户消息序号等转换为平台发送请求。应用身份必须来自当前已鉴权 TCP 连接绑定的 `cmppAccount`；Submit `MsgSrc` 是独立的企业代码，必须与该应用 `cmppEnterpriseCode` 匹配，不得把 `MsgSrc` 当作登录账号查找应用。
 7. 下游 CMPP Submit 进入平台后，不创建客户端批量任务，但必须按手机号维度创建 `sms_message_record`，source 标记为 `cmpp`，并保留客户侧 sequence/msgId 映射。
 8. 下游 CMPP Submit 必须复用 NestJS 发送前校验：企业/应用状态、IP 白名单、签名/模板报备、模板匹配策略、风控、黑名单、余额/授信、运营商识别、通道组路由。
 9. 对客户 Submit 的响应必须符合 CMPP 协议：参数错误、鉴权失败、余额不足、模板或签名未通过、无可用通道、风控拒绝等应映射为明确失败状态；已接收进入平台发送链路时返回成功并生成可追踪平台 messageId。
@@ -1005,8 +1005,10 @@
 - 预期结果：
  - 17890 是真实 CMPP Server 监听，不是 HTTP 端口。
  - bind 阶段调用真实 NestJS API 校验账号、密码、企业状态、认证状态、应用状态、短信接口开关和 IP 白名单。
+  - CMPP2.0 和 CMPP3.0 连接分别返回对应版本 ConnectResp，后续 Submit/Deliver 按该 TCP 连接协商版本解包和组包，不发生字段错位。
  - 密码错误、应用停用、企业停用、短信接口关闭、IP 不在白名单时 connect/login 被拒绝。
  - submit 被接受后返回 CMPP SubmitResp 成功，并在真实数据库创建 `sourceType=cmpp` 的发送记录，进入真实发送链路。
+  - Submit 应用身份使用 bind 已鉴权账号；`MsgSrc` 使用应用级企业代码并独立校验。企业代码与登录账号不同时仍能正确定位应用，企业代码不匹配时返回失败。
  - submit 内容不匹配审核模板、余额不足、短信接口关闭、无可用通道时返回明确失败，不得伪造成功。
  - Gateway 对每次 submit 记录 `submit_received` 和 `submit_accepted`/`submit_rejected`；日志可按账号、IP、sequenceId、号码和 messageId 定位，拒绝时包含 NestJS 真实业务原因和 CMPP result，但不包含明文短信正文。
  - CMPP 包在进入 handler 前因长度、命令字、读包或 Unpack 失败时，Gateway 记录 `read/unpack packet failed`、远端地址、协议模式、错误类型和原始错误，不得静默断开。
@@ -658,6 +658,8 @@ npm run verify:phase8
 - Gateway HTTP 回调在 NestJS 返回非 2xx 时保留最多 64KB 响应体，客户 Submit 失败日志可直接显示模板不匹配、IP 白名单、余额或路由等真实业务原因，不再只显示 HTTP 状态码。
 - 日志不记录明文短信正文，仅记录字符数和 MD5 哈希，便于比对同一内容且避免日志泄露。
 - 将当前 gocmpp 版本固定为仓库内小型 fork，仅在 server 循环补充底层诊断：包在进入业务 handler 之前发生长度、命令字、包体读取或 Unpack 失败时，记录 `read/unpack packet failed`、远端地址、库解析协议模式、Go 错误类型和原始错误；正常 EOF 断开不记为解包失败。
+- 生产复现确认 CMPP2.0 客户 Submit 被固定 CMPP3.0 解包导致 `MsgSrc/手机号/内容` 错位为空。现在 gocmpp server 按 CONNECT `Version` 将每条连接切换到 CMPP2.0/2.1/3.0 解包模式，并返回同版本 ConnectResp、SubmitResp 和 Deliver。
+- Gateway 使用 bind 时已鉴权会话账号调用 NestJS 入站接口，Submit `MsgSrc` 改为与鉴权返回的应用级 `cmppEnterpriseCode` 独立比对，不再将企业代码误当登录账号。

 ### 验证状态

@@ -665,6 +667,7 @@ npm run verify:phase8
 - `go test ./... -count=1`：通过。
 - `go build ./cmd/gateway`：通过。
 - 真实 TCP 非法包用例：向入站端口写入非法 `total_length`，确认业务 handler 未执行时仍产生 `read/unpack packet failed` 日志。
+- CMPP2.0 真实集成用例：客户使用与登录账号不同的 `MsgSrc=SP0001`，完成 V20 ConnectResp、Cmpp2SubmitReq/Resp 和 Cmpp2Deliver Receipt，NestJS 收到的 account 仍为 bind 账号：通过。

 ## 2026-07-07 Gateway 上游提交与下游 Deliver 闭环补齐