Rodger-Wang
|
268ce26bc9
|
services,admin: 凭据归一到 svc_config；后台服务配置菜单收敛；品牌商与公码下架
这一提交里有两条相对独立的线，落在同一批文件上（server.go / core.go / model.go /
CLAUDE.md 等被两边同时改到），按文件拆不开，故合并提交。
── 一、第三方凭据归一到 svc_config，后台「服务配置」从 11 项收敛到 6 项 ──
起因：凭据同时躺在两张扁平 key/value 表里——应用业务库的 config 与 console 库的
global_config，而合并下发时**全局那张赢**。同一个 AZURE_SPEECH_REGION /
OPENAI_API_KEY / VOLC_OPENSPEECH_APP_ID / XUNFEI 密钥在两边值不一样，运营在
「应用环境配置」里改半天没有任何效果，且不报错。global_config 还按区域整份复制
（14 区 × 31 键 = 473 行），实测其中 27 个键是各区同值。
- comm.SvcField 新增 EnvKey（后台字段表里的「下发键名」列）：非空时该字段的明文值
同时以这个名字出现在 user_getappconfig 的 env 里。已发布的客户端只读 env，
靠它继续供货、无需发新包；新客户端直接读结构化的 thirdsvcs。
- env 覆盖层与 thirdsvcs 走同一份 VIP 过滤，否则 VIP 过期的用户虽拿不到 AST 条目，
却仍能从 env 里读出同一套通话翻译凭据，那道闸门就形同虚设。
- 同作用域内 env_key 不允许重名（checkSvcEnvKeys 在保存时拦）：重名时下发结果取决于
服务 id 排序，表现为「凭据时对时不对」。
- 一次性迁移 migrate_envtosvc.go（console 每次启动跑、幂等）：基础值取中国区现值，
只有与基础值不同的区域才写 svc_region_override，473 行收敛到几十行。
顺带修了两行填错列的历史数据（group 里是键名、key 里是值），正是它让
ALIBABA_BAILIAN_APP_ID/WORKSPACE_ID 恒为 null、客户端一直用代码里写死的兜底值。
不删 global_config 的行（不可逆的线上凭据，留作回退依据），确认跑稳后由人手工 DROP。
- 后台：「第三方服务配置」改名「服务与环境配置」，「应用环境配置」并为其第二个标签页；
「全局环境配置」下线只留重定向；Agent 配置、通话翻译配置、会议记录服务三页删除
（前两者对应的 agent_config、call_translate_rule 两表在测试机与正式机上都是 0 行）。
⚠️ 会议记录服务删的只是后台入口，echomeet_orch 的数据与运行时都还在（两台机各 4 行，
是语音纪要识别/翻译/总结的服务选型来源），要换服务商现在只能直接改库。
阿龙测试环境实测：迁移前后 env 逐键比对，48/54 键值完全一致，丢失的 8 个全部是预期
丢弃（ALIBABA_OSS_* 与 COMMENT_* 无人读取、两个填错列的垃圾键名），无一个值发生变化。
验证中发现并修掉四个都不报错的坑：空值不能下发成 env 键（Dart 的 ?? 只兜 null，
空串会把默认值顶掉）、区域覆盖里的空串会把基础值抹成空、服务 enable=false 等于凭据
一个都不下发、启动时的模板补字段会给实例加空的加密字段导致误报「缺凭据」且保存被拒。
── 二、品牌商(identity=3)与公码下架 ──
brand 表、公码 authcode 及其全部后台页面与接口移除；账号作用域不再有 brandId，
设备/结算的归属改由渠道商推导。这部分不是本次会话中由 Claude 编写的。
验证：go build ./... + go vet ./... 通过，comm/console/user/echomeet/api 各包测试全绿；
admin npm run build 通过。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
4 weeks ago |
|
Rodger-Wang
|
8d580a545d
|
文件上传改走服务端签发预签名 URL，客户端直传阿里云 OSS
客户端不再持有对象存储的长期密钥。
旧实现用腾讯云 COS SDK 直连，bucket 与 SecretId/SecretKey 明文随
user_getappconfig 的 env 下发给每一个 App 用户（config 表的 COS_* 那几个键）。
抓包或反编译就能拿到这对长期密钥，而它对整个桶有读写权限——不只是自己那部分，
User/ 下所有人的录音都能被拉走或删掉。
现在：新增 user_getuploadurl，服务端签发 15 分钟有效、且只对某一个 object key
生效的阿里云 OSS 预签名 PUT URL，客户端拿着它直传。存储与 console 后台传固件/
产品图同一个桶（ymaioss），不再是两个云厂商两套存储。
服务端
- 新接口 modules/user/api_getuploadurl.go：
· object key 由服务端拼死 EAIMAR/User/<uid>/<scene>/<yyyy/MM/dd>/<12位随机>.<ext>，
uid 取自会话不采信客户端，客户端连自己传到谁的目录下都决定不了；
· scene 白名单 LocalAudio / TranslatAudio / ExternalAudio / ChatImages
——加新场景前要把客户端 addUpload 与 UploadOss.upload 的调用点全捞一遍，
少一个值就是那条链路整条报错，且只在真机跑到才发现；
· 扩展名白名单决定 Content-Type，不在表里直接拒，不回退成
application/octet-stream（那等于把桶变成任人上传的网盘）；
· 随机名用 crypto/rand 而非 math/rand：key 可枚举就等于别人能猜到录音地址。
- 抽出 comm/ossconf.go：OSS 配置读取、上传根前缀、publicURL 拼接从 console 挪来，
console 改为调用它。两边必须落同一个桶，各写一份迟早漂移。
解密用 ${FIELD_ENCRYPT_KEY}，console 与业务服务本就必须配同一把。
客户端
- upload_oss.dart 重写为「要 URL → dio 流式 PUT」，upload() 签名与返回值不变，
MeetingUploadService 不用改。用独立 Dio 实例：项目那个挂着 AuthInterceptor，
会加 token 与业务签名头、还会把响应按业务 JSON 解析，直传 OSS 时全是多余，
签名头还可能与预签名冲突。
- Content-Type 必须用服务端回带的值，它计入了签名，写别的会 403。
- agent 图片的 rootDir 从 'User/<uid>/ChatImages' 改成 'ChatImages'：
前缀由服务端加，客户端再拼一层就是重复路径。
真机验证：录音落到
https://oss.ymaikj.com/EAIMAR/User/<uid>/LocalAudio/2026/09/04/howXMScPdsNP.wav，
下载 212524B 与库里 size 逐字节一致，Content-Type=audio/wav，文件头 RIFF/WAVE。
其余三个 scene 走同一段代码但尚未实跑。
⚠️ 新老客户端并存：老包仍读 COS_* 直传腾讯云，config 表里那 5 个键先别删；
历史录音的 audiourl 是 COS 绝对地址，不会自动搬家。
⚠️ 录音目前仍是公共可读的（bucket 公共读，实测匿名 GET 206、不存在的 key 404），
只靠 12 位随机 key 不可猜测来保护。要锁住得转私有桶 + 播放时也签临时读 URL，未做。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
1 month ago |
|
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
|
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
|
1639cf35a0
|
上传代码
|
2 months ago |
|
liwei1dao
|
aca7204e57
|
上传代码
|
2 months ago |
|
liwei1dao
|
8924a3cd3b
|
上传服务后台代码
|
2 months ago |
|
liwei1dao
|
948e368996
|
上传代码
|
2 months ago |
|
liwei1dao
|
59e54eb575
|
上传发布版本
|
2 months ago |
|
liwei1dao
|
6f7cfe3bb2
|
上传主版本
|
2 months ago |
|
liwei1dao
|
a36f0a016a
|
上传服务端代码
|
2 months ago |
|
liwei1dao
|
7660f33258
|
上传最新代码
|
2 months ago |
|
liwei1dao
|
97ecbf9df5
|
上传新版本的管理后台
|
2 months ago |
|
liwei1dao
|
66d561dc1b
|
上传代码
|
4 months ago |
