Rodger-Wang
d7fad60658
设备表合表:license_<pid> 分表 → 全局 device_mac,只按 MAC 校验
设备的身份是它自己的 MAC,本来就全局唯一,定位一台设备不需要 pid。
原先按产品切分表,pid 既是查询键、又得由客户端猜出来,猜错就报
"这台 MAC 没登记在该产品下"——提示指向数据缺失,实际数据好好的。
触发改造的事故:一台已正确导入的 DEEPVOICE 耳机(MAC 在 license_b022,
产品 45090,status=0 未绑过)连不上、弹"设备连接受限"。根因是产品 45090
的 devicetype 被配成 2(BLE双端)而不是 1(经典蓝牙):客户端
_resolveProductId 第一步就 where(devicetype==1) 把整个产品滤掉,候选只剩
Echo-one,名字互不包含 → 兜底退回 headsets.first.id = 45091,服务端拿错
pid 去 license_b023 查,自然查不到。而且就算 pid 猜对也过不去——服务端
只有 devicetype==1 才走 MAC 反查,2 会走 else 分支从空 code 反解 pid、
回退写死的 45058。
改动:
- 新增全局表 device_mac(comm.TableDeviceMac),主键 code = MAC;
productid 降为归属列,不再是查询键。TableLicense 标记废弃,只留给迁移读。
- registry.go 的 migrateLicenseToDeviceMac 每次启动跑、幂等:
① code := devicemac 修存量 → ② 按两表列名交集做 INSERT ... ON CONFLICT
DO NOTHING(不能 SELECT *:各分表建于不同时期,有的多 factoryid/probatch)
→ ③ productid 为空的用表名里的 pid 补上。孤儿分表里也是真实发出去的设备,
一并搬。搬完刻意不删旧表——不可逆数据,旧表是出问题时唯一的回退依据。
- binddevice / unbinddevice 改为先按 code 再按 MAC 全局定位,命中行的
productid 才是产品。req.Pid 不再采信。杰理链路也顺带不需要 devcode
反解 pid 了。
- 新增 comm.ScopeToProduct:合表后分表那层天然隔离没有了,每个"按产品"
的读写都必须显式带 productid,漏一处就跨产品操作——查询多列几行只是
难看,批量禁用 / 按批次删除漏掉就是删别人产品的数据。它会把调用方的
条件整体括起来,防止 "a=? or b=?" 让 or 把 productid 短路掉。
- 导入查重改成全局:同一个 MAC 出现在两个产品下会让按 MAC 反查出现歧义。
- 客户端删掉 _resolveProductId,binddevice 只报 MAC 不传 pid。
按需求明确不做应用隔离:MAC 存在即放行。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 month ago
Rodger-Wang
90abb0ad42
身份证实名核验、翻译与新用户开户礼
本次会话开始前就已存在于工作区的改动,一并提交。主要是三块:
1) 身份证实名核验(sys/idverify + user 模块)
接入阿里云 Id2MetaVerify、腾讯云 IdCardVerification、创蓝三家 provider,
无状态工厂——配置在 svc_config 里按应用作用域存,调用时才解析。
客户端接口 user_idverify / user_getidverify。
凭据是云账号主 AK/SK,故新增服务端专用类别 comm.SvcCatIdVerify=11,
由 svcresolve.go 在下发口整条跳过,svcpool_serveronly_test.go 守着这条底线。
2) 翻译(sys/aliyun/translate + comm/lang.go)
语言码归一与阿里云翻译调用。
3) 新用户开户礼(newuser_gift.go)
配套 api_sgin 建号流程。
注:go test ./modules/user/ 里的 TestApiProbeAppConfigV3 会失败,但与本次改动无关
——那是打线上接口的联调探针,硬编码的域名 app-dev.voitrans.net 已废弃、JWT 也过期了,
该文件自 b2577e16 起未改动过。go test -short 会跳过它,其余全部通过。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 month ago
Rodger-Wang
0663446f0c
运行日志 apps/services/comm/log 移出版本管理
lego 未配置日志路径时会在工作目录写 ./log,本地跑一次服务或 go test 就被覆写一次,
每次都产生一条无意义 diff(内容是同一条微信支付密钥解密失败的告警,只有时间戳在变)。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 month ago
Rodger-Wang
db47e0f3f0
游客登录入口改为后台按版本控制
需求:后台一个开关控制游客登录按钮显隐,且只对指定版本号的客户端生效,
其余版本一律隐藏(应用商店送审场景:只给正在过审的那一版开)。
白名单语义(comm.ChannelApp.ShowTourists):
- tourists=false → 全部隐藏
- tourists=true 且 touristsversion 空 → 全部隐藏(没点名任何版本 = 谁都不放行)
- tourists=true 且 touristsversion=X → 只有版本号等于 X 的客户端可见
留空按"全隐藏"而非"全放行"是刻意选的失败方向:判宽的后果是不该露游客入口的版本
露了出去(过审风险、白嫖新用户开户礼),判严只是入口少显示。要全部隐藏就取消勾选,
后台 saveChannelApp 会拒绝"勾了开关却没填版本"这种等于没开的配置。
判定放在服务端,与 NeedForceUpdate/IsReviewing 同规矩:客户端在 user_getchannelapps
的请求里带 version,服务端把每条渠道配置的 tourists 换算成结论再下发。版本比较各端
各写一遍必然出现实现不一致,而这个开关直接关系到过审,判错代价高。
touristsversion 是 channel_app 的后加列,console 启动时用 ADD COLUMN IF NOT EXISTS
补上——CreateTable 对已存在的表跳过 AutoMigrate,不补就永远没这列。
注:db.proto / user_msg.proto / CLAUDE.md 里另有先于本次改动就存在的编辑,一并带上。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 month ago
liwei1dao
bb3b1c7a3a
上传代码
2 months ago
liwei1dao
b2577e16fa
上传最新的平台代码
2 months ago
liwei1dao
af05ff12ce
上传代码
2 months ago
liwei1dao
1639cf35a0
上传代码
2 months ago
liwei1dao
aca7204e57
上传代码
2 months ago
liwei1dao
554a4ab501
上传最新的版本代码
2 months ago
liwei1dao
948e368996
上传代码
2 months ago
liwei1dao
59e54eb575
上传发布版本
2 months ago
liwei1dao
7660f33258
上传最新代码
2 months ago
liwei1dao
18ffb48466
上传代码
2 months ago
liwei1dao
e270cf89b6
上传新版本管理后台
2 months ago
liwei1dao
6e5da54cf8
上传代码
3 months ago
liwei1dao
af9e210f9a
会议记录接入后台服务编排:三段独立选路+客户端可选总结模型,移除旧 yaml 四套凭据模式
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3 months ago
liwei1dao
a25b0c9fc0
上传最新的服务后台代码
3 months ago
liwei1dao
040af15192
上传基础服务代码
3 months ago
liwei1dao
d7445984cb
添加 授权吗 的方案
3 months ago
liwei1dao
197d544062
上传管理后台的系统升级和服务配置逻辑优化
3 months ago
liwei1dao
99de0fa26f
上传代码修复
3 months ago
liwei1dao
1390f50144
优化邮件登陆服务
3 months ago
liwei1dao
eaecd00d20
上传基本版本
3 months ago
liwei1dao
1d25322437
上传当前版本
3 months ago
liwei1dao
ce15363123
上传服务端代码优化
4 months ago
liwei1dao
188a0f5c55
上传版本服务服务集群代码和管理后台
4 months ago
liwei1dao
715f8e3818
上传厨师版本
4 months ago