 chengma
|
f0715ee273
|
feat: 支持 MySQL 公网 TLS CA 校验 (#86)
|
2026-08-10 09:59:09 +08:00 |
|
|
chengma
|
ddce0f6679
|
docs: 记录 MySQL 公网白名单规则 (#85)
|
2026-08-10 09:44:24 +08:00 |
|
|
chengma
|
04a777dc8e
|
feat: 支持从 config.yaml 读取 MySQL 配置 (#83)
|
2026-08-10 09:24:04 +08:00 |
|
|
chengma
|
05a54b044d
|
feat: 统一顺运宝日期同步并记录历史 (#59)
|
2026-08-09 18:22:58 +08:00 |
|
|
chengma
|
4b5cd13807
|
fix: 增强顺运宝同步完整性保护 (#58)
|
2026-08-09 17:17:42 +08:00 |
|
|
chengmaandClaude Opus 5
|
2e686b17a4
|
feat: 顺运宝登录接入验证码自动识别 (#47)
#46 的登录只有手工输验证码一条路，而会话 24 小时就过期——每天第一次
同步都得有人在场，将来也做不了定时同步。
docs/admin/08 §8 当时写死"不引入 OCR 服务"，理由是"多一个必须先启动的
东西"。那条判断基于示例脚本里的 http://127.0.0.1:8000/ocr（本机服务）。
用户提供了托管地址后前提不成立，本工单推翻它——文档里改写并保留原文，
让后来人知道这个决定变过、为什么变。
OCR 优先、手工兜底：识别成功直接登录，失败或服务不可达降级到 #46 已有的
手工弹窗，并在弹窗里说明是"已尝试 N 次"还是"服务不可用"。手工路径不删，
外部服务挂了不该让整个同步功能不可用。
识别失败也是 code:200。实测拿无文字图片探测 https://ocr.ilapage.cn/ocr
返回 {"code":200,"message":"Success","data":""}——不是错误码。所以
Recognize 只负责"这次 HTTP 调用有没有问题"，空 data 照常返回 (", nil)，
业务校验交给调用方；空 data 和长度不对收敛到同一个 len(code) != 4，
一条规则覆盖两种情况。
不合格的验证码不拿去登录：白费一次尝试，且频繁错误登录可能触发风控。
审查时变异测试发现这条没有测试守着——原测试只断言"重新取图了"和
"最终登录成功"，禁用长度校验后依然成立。已补 loginRecorder 记录每次
提交到 /am/auth/login 的 code，断言登录只被调用一次且提交的是合格的那个。
每次重试重新取图（同一张图再识别结果一样，且可能已被上次失败的登录作废）；
OCR 用独立 HTTP 客户端不带顺运宝 Cookie；验证码图片只在内存里传，不落盘。
OCR 不可达立即降级、不占用重试次数——对着连不上的地址重试 5 次，
操作员要等 50 秒才看到手工输入框，结果注定一样。
测试全部用 httptest，不打真实的 ocr.ilapage.cn 和 shunyunbaoerp.com。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-09 12:35:02 +08:00 |
|
|
chengmaandClaude Opus 5
|
512ccf34d6
|
docs: 新增顺运宝接口契约；config.yaml 加入 gitignore
从 4 份 HAR 抓包和示例脚本还原 docs/admin/08-顺运宝接口.md。
全部结论标了出处，只有单一样本支撑的都标了 [待定]。
抓包验出三件和现有假设不符的事：
1. 登录响应的 JWT 从不参与请求，认证全靠 Cookie。示例脚本里
self.token 只用于算缓存有效期，没进过任何请求头。Go 侧存 Cookie
即可，token 都不用存。
2. _capture_refreshed_token 是死代码——它从响应头 X-Requested-With
读刷新后的 JWT，而 4 份 HAR 共 18 个响应里带该头的是 0 个。
会话就是 24 小时硬上限，没有滚动续期，不要移植这段逻辑。
3. 金额单位在同一个响应里不统一：amtOrder 在列表接口是分（61200
对应 612.0），escrowAmount 却不是（505 对应 505.0）。不能假设
"列表接口的金额都是分"，逐字段确认。这条只有一个样本，已标 [待定]。
还推翻了「货运单规格能直接对上蝦皮商品規格ID」这个前提：顺运宝给的
productId 是 11 位商品ID，蝦皮規格ID 是 12 位。但 productSpec 的格式
与蝦皮报表完全一致，可直接复用 #38 的 ParseSpec，匹配走
"productId 定位商品 → 解析规格 → 在该商品的 SKU 里比对"。
admin/config.yaml 含明文密码且此前没有任何 gitignore 规则挡它，
一次目录级 git add 就会进历史。已加规则，并补 config.example.yaml
作为模板（不含真实凭据，进 git）。
已确认历史提交中从未出现过该凭据。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-09 10:59:00 +08:00 |
|