starpivot

Commit Graph

Author	SHA1	Message	Date
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

14 Commits (dbf7f2403b0ddf693ab212ab2b6833bb79fbc7b4)