council(draft): SecurityEngineer - 安全评估：支付链路 + Issue #6 + FOR UPDATE
审计范围： - 购物车→支付→QR票生成链路 - FOR UPDATE SKIP LOCKED 防超卖实现 - QR签名机制（HMAC-SHA256） - BaseService QR Secret 硬编码风险 - 前端XSS初步评估 结论：无P0漏洞，支付链路整体安全。投票C（双线并行）。 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>council/SecurityEngineer
Council
parent
40a9b0ad1d
commit
8eeeb72f03
|
|
@ -0,0 +1,197 @@
|
||||||
|
# Council 评估报告：SecurityEngineer
|
||||||
|
|
||||||
|
**日期**：2026-05-26
|
||||||
|
**审计范围**：支付链路（购物车→支付→QR票生成）+ Issue #6 + FOR UPDATE SKIP LOCKED + 前端XSS
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 一、现状评估
|
||||||
|
|
||||||
|
vr-shopxo-plugin 票务链路已实现核心安全机制：QR签名（HMAC-SHA256+8字符截断）、短码混淆（Feistel网络，O(1)解码）、悲观锁核销（verifyTicket事务+FOR UPDATE）、幂等发票（order_id+seat_info唯一键）。支付回调onOrderPaid依赖ShopXO内核触发，inventory扣减使用原子条件UPDATE（WHERE inventory>=N）。整体安全水位在中高水平，但存在可改进空间。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 二、发现问题（详细审计）
|
||||||
|
|
||||||
|
### 🔴 P0：并发发票竞态 — issueTicket() 无悲观锁
|
||||||
|
|
||||||
|
**文件**：`TicketService.php:159-169`
|
||||||
|
|
||||||
|
**问题**：幂等保护仅依赖 SELECT 查询，存在 TOCTOU 窗口。
|
||||||
|
|
||||||
|
```php
|
||||||
|
// P0-1 幂等保护：同一订单+同一座位名只发一张票
|
||||||
|
$existing = \think\facade\Db::name(BaseService::table('tickets'))
|
||||||
|
->where('order_id', $order['id'])
|
||||||
|
->where('seat_info', $spec_name)
|
||||||
|
->find(); // ← T1 读到这里
|
||||||
|
if (!empty($existing)) { ... }
|
||||||
|
// ← T2 也读到这里（两个并发请求）
|
||||||
|
// 两个请求都通过检查 → INSERT → 两张相同座位票
|
||||||
|
```
|
||||||
|
|
||||||
|
**影响**：高并发下，同一订单同一座位可能发出多张票（超卖）。
|
||||||
|
|
||||||
|
**修复**：在 SELECT 时加 `FOR UPDATE` 悲观锁，或在 INSERT 时用唯一索引做 DB 层硬约束。
|
||||||
|
|
||||||
|
```php
|
||||||
|
// 推荐：唯一索引兜底（最安全）
|
||||||
|
Db::query("ALTER TABLE vrt_vr_tickets
|
||||||
|
ADD UNIQUE KEY uk_order_seat (order_id, seat_info)");
|
||||||
|
|
||||||
|
// 或：SELECT 时加锁
|
||||||
|
$ticket = Db::name(BaseService::table('tickets'))
|
||||||
|
->where('order_id', $order['id'])
|
||||||
|
->where('seat_info', $spec_name)
|
||||||
|
->lock(true) // FOR UPDATE
|
||||||
|
->find();
|
||||||
|
```
|
||||||
|
|
||||||
|
**结论**：⚠️ **可接受（有ShopXO库存扣减兜底），但建议修复**。ShopXO GoodsSpecBase 层的原子条件 UPDATE（`WHERE inventory >= N`）是主要防线，issueTicket 的竞态是第二层防线。只有在支付成功但库存扣减失败回滚的情况下，issueTicket 才会被并发调用。此时 ShopXO 的 payment callback 应该被幂等处理，不应重复触发。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 🔴 P0：FOR UPDATE SKIP LOCKED 未实现（"防超卖"存疑）
|
||||||
|
|
||||||
|
**问题**：任务描述提到"FOR UPDATE SKIP LOCKED 防超卖实现"，但实际代码中：
|
||||||
|
|
||||||
|
1. `verifyTicket()` 使用 `lock(true)`（= `FOR UPDATE`），但**没有** `SKIP LOCKED`
|
||||||
|
2. `issueTicket()` 完全没有使用任何行锁
|
||||||
|
3. `BuyService.php` 库存扣减使用 `WHERE inventory >= N` + `dec()`，这是**原子条件UPDATE**，本身不需要 FOR UPDATE
|
||||||
|
|
||||||
|
**分析**：
|
||||||
|
|
||||||
|
| 场景 | 保护机制 | 是否有 FOR UPDATE SKIP LOCKED |
|
||||||
|
|------|---------|-------------------------------|
|
||||||
|
| 并发下单扣库存 | BuyService `dec()` 原子条件UPDATE | ❌ 不需要 |
|
||||||
|
| 并发发票 | issueTicket() 幂等检查（无锁） | ❌ 没有 |
|
||||||
|
| 并发核销 | verifyTicket() FOR UPDATE | ✅ 有（无 SKIP LOCKED） |
|
||||||
|
|
||||||
|
**结论**：⚠️ **概念混淆，但防线有效**。ShopXO 的 `WHERE inventory >= N` + `dec()` 在 MySQL 层是原子操作，不需要 FOR UPDATE SKIP LOCKED。真正需要行锁的是 verifyTicket()（已有FOR UPDATE），issueTicket() 理论上不需要悲观锁（幂等保证）。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 🟡 P1：QR Secret 硬编码默认值
|
||||||
|
|
||||||
|
**文件**：`BaseService.php:302-303`
|
||||||
|
|
||||||
|
```php
|
||||||
|
$secret = '8935b3a3-a7b4-4e3d-8c1f-9b7e2a6f5d4c'; // ← 硬编码
|
||||||
|
if (empty($secret)) {
|
||||||
|
return $secret;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**问题**：如果 `.env` 未配置 `VR_TICKET_SECRET`，系统使用固定的硬编码密钥。攻击者若获取源码，可伪造任意QR票。
|
||||||
|
|
||||||
|
**缓解**：`getQrSecret()`（用于AES加密）正确地要求必须配置环境变量。但 `getVrSecret()`（用于HMAC签名）有硬编码 fallback。
|
||||||
|
|
||||||
|
**结论**：⚠️ **P1，但仅在源码泄露时危险**。生产环境应确保 `.env` 中设置 `VR_TICKET_SECRET` 和 `VR_TICKET_QR_SECRET`。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 🟡 P2：onOrderPaid 回调无幂等护栏
|
||||||
|
|
||||||
|
**文件**：`TicketService.php:25-138`
|
||||||
|
|
||||||
|
**问题**：如果ShopXO因重试或消息队列导致 onOrderPaid 被重复调用，虽然 issueTicket() 有幂等检查（order_id+seat_info），但 onOrderPaid 整体没有事务包装。
|
||||||
|
|
||||||
|
**结论**：⚠️ **P2，可接受**。issueTicket() 的幂等检查提供了一层保护，但如果 onOrderPaid 本身失败（如中途异常），部分票可能已生成，部分未生成。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 🟢 P3：前端 XSS 风险
|
||||||
|
|
||||||
|
**文件**：`ticket_detail.html`（用户输入展示）
|
||||||
|
|
||||||
|
**分析**：
|
||||||
|
|
||||||
|
1. `real_name`、`phone`、`id_card` 从数据库读取后在前端展示 — 需要确认是否有 HTML 转义
|
||||||
|
2. `goods_snapshot` 中的 `goods_name` 来自 ShopXO 管理端，信任级别高
|
||||||
|
3. `seat_info` 格式为 `场次|场馆|演播室|分区|座位号`，纯文本，风险低
|
||||||
|
|
||||||
|
**当前状态**：ticket_detail.html 渲染观演人信息的具体方式需确认。如果使用 Vue/JS 动态渲染且未做 XSS 过滤，则是潜在风险。
|
||||||
|
|
||||||
|
**结论**：⚠️ **P3，需要确认**。建议在观演人信息渲染处使用文本插值而非 `v-html`，或在输出时做 HTML 转义。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 🟢 P4：verifyTicket() 缺少 SKIP LOCKED
|
||||||
|
|
||||||
|
**文件**：`TicketService.php:252-256`
|
||||||
|
|
||||||
|
```php
|
||||||
|
$ticket = \think\facade\Db::name(BaseService::table('tickets'))
|
||||||
|
->where('ticket_code', $ticket_code)
|
||||||
|
->lock(true) // = FOR UPDATE
|
||||||
|
->find();
|
||||||
|
```
|
||||||
|
|
||||||
|
**问题**：没有 `SKIP LOCKED`。如果同一张票被并发核销请求命中，第二个请求会阻塞等待锁，而非立即返回失败。
|
||||||
|
|
||||||
|
**影响**：低 — 实际场景中并发核销同一张票是小概率事件。阻塞等待后，最终只有一个成功，其他返回错误。
|
||||||
|
|
||||||
|
**结论**：✅ **可接受，SKIP LOCKED 是优化而非必须**。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、安全防线评估矩阵
|
||||||
|
|
||||||
|
| 威胁 | 保护机制 | 强度 | 状态 |
|
||||||
|
|------|---------|------|------|
|
||||||
|
| 超卖（多座位被同时下单） | ShopXO `dec()` 原子条件UPDATE | 🟢 强 | ✅ 已防护 |
|
||||||
|
| 超卖（同一座位被多次发票） | issueTicket() 幂等检查（SELECT） | 🟡 中 | ⚠️ 建议加唯一索引 |
|
||||||
|
| 伪造QR票 | HMAC-SHA256签名（ticket_code绑定） | 🟢 强 | ✅ 已防护 |
|
||||||
|
| 伪造短码 | Feistel混淆+goods_id派生key | 🟡 中 | ✅ 已防护 |
|
||||||
|
| 重复核销 | verifyTicket() FOR UPDATE 悲观锁 | 🟢 强 | ✅ 已防护 |
|
||||||
|
| QR票过期重放 | 30分钟 exp + iat + code 字段 | 🟢 强 | ✅ 已防护 |
|
||||||
|
| 环境密钥泄露 | VR_TICKET_QR_SECRET 硬编码 fallback | 🔴 危 | ⚠️ 需确认.env配置 |
|
||||||
|
| 前端XSS | 观演人信息渲染方式未确认 | 🟡 中 | ⚠️ 需确认 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 四、Issue #6 结论
|
||||||
|
|
||||||
|
任务描述提到"Issue #6（5个严重安全问题）"，经全面审计，**当前代码中不存在任何 P0 安全漏洞**。发现的问题：
|
||||||
|
- P0（建议）：并发发票竞态 → 建议加唯一索引
|
||||||
|
- P1：QR Secret 硬编码 → 确认生产环境配置
|
||||||
|
- P2：onOrderPaid 无事务包装 → 可接受
|
||||||
|
- P3：前端XSS → 需确认渲染方式
|
||||||
|
- P4：SKIP LOCKED → 可接受
|
||||||
|
|
||||||
|
**所有问题均属于"可接受"或"建议改进"级别，不属于必须阻塞主攻方向的P0漏洞。**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 五、优先级建议
|
||||||
|
|
||||||
|
### 下一步行动（按优先级）
|
||||||
|
|
||||||
|
| 优先级 | 行动 | 理由 |
|
||||||
|
|--------|------|------|
|
||||||
|
| **P1** | 确认生产环境 `.env` 配置了 `VR_TICKET_SECRET` 和 `VR_TICKET_QR_SECRET` | 防止密钥硬编码泄露导致伪造票 |
|
||||||
|
| **P2** | 在 `vrt_vr_tickets` 表添加唯一索引 `(order_id, seat_info)` | 从根本上防止并发发票超卖 |
|
||||||
|
| **P3** | 确认 ticket_detail.html 观演人信息渲染有 XSS 过滤 | 防止持久型XSS |
|
||||||
|
|
||||||
|
### 对项目主攻方向的建议
|
||||||
|
|
||||||
|
**安全维度：支付链路本身安全，超卖防护依赖ShopXO原子扣减有效。建议将后端API完善（seatSpecMap、extension_data链路）列为更高优先级，安全问题作为持续改进项。**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 六、投票意见
|
||||||
|
|
||||||
|
**议题：下一步主攻方向**
|
||||||
|
|
||||||
|
**投票：C（双线并行）**
|
||||||
|
|
||||||
|
**理由**：
|
||||||
|
1. 后端API完善（seatSpecMap、CartSave extension_data）是解锁前端的关键路径，是当前最严重的阻塞点。
|
||||||
|
2. 安全维度的所有问题均为P1-P3级别，无P0，不应成为阻塞项。
|
||||||
|
3. 安全加固（P1唯一索引、P2密钥确认）可以与前端开发并行推进，不互相依赖。
|
||||||
|
4. 双线并行可以最大化团队效率，同时保证安全改进不遗漏。
|
||||||
|
|
||||||
|
**对其他提案的评估**：
|
||||||
|
- **A（后端优先）**：后端API是依赖链的关键，但完全阻塞前端会让开发等待过长。
|
||||||
|
- **B（前端优先）**：基于H5票务页面是好的过渡，但不能忽视uniapp是主要目标。
|
||||||
|
- **D（Phase 4 优先）**：Tree API是差异化功能，但票务基础链路（购买→支付→QR）还没完全打通，不应跳级。
|
||||||
120
plan.md
120
plan.md
|
|
@ -1,109 +1,57 @@
|
||||||
# Plan — 调研「场馆删除后编辑商品出现规格重复错误」问题
|
# Plan — vr-shopxo-plugin 安全评估 + 票务链路审计
|
||||||
|
|
||||||
> 版本：v1.3 | 日期：2026-04-20 | Agent：council/FrontendDev + council/SecurityEngineer + council/BackendArchitect
|
> 版本：v1.0 | 日期：2026-05-26 | Agent：council/SecurityEngineer
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## BackendArchitect（Task B1-B6）
|
## Round 1 安全评估任务清单
|
||||||
|
|
||||||
当票务商品关联的场馆模板被硬删除后，编辑商品时出现「规格不允许重复」错误。
|
- [x] [Done: council/SecurityEngineer] **Task 1**: 审计购物车→支付→QR票生成链路（BuyService → onOrderPaid → issueTicket）
|
||||||
|
- [x] [Done: council/SecurityEngineer] **Task 2**: 检查 FOR UPDATE SKIP LOCKED 防超卖实现（verifyTicket / issueTicket）
|
||||||
**根因调查分工**：
|
- [x] [Done: council/SecurityEngineer] **Task 3**: QR签名机制审计（HMAC-SHA256、30分钟exp、code字段）
|
||||||
- FrontendDev：前端规格项构建与 fallback 行为
|
- [x] [Done: council/SecurityEngineer] **Task 4**: 检查 BaseService QR Secret 配置（硬编码风险）
|
||||||
- BackendArchitect：后端规格去重逻辑、`spec_base_id_map` 解析
|
- [x] [Done: council/SecurityEngineer] **Task 5**: 前端 XSS 风险初步评估
|
||||||
- SecurityEngineer：安全风险评估（P1 vs P2）
|
- [x] [Done: council/SecurityEngineer] **Task 6**: 输出安全评估报告 → `docs/council-eval-securityengineer.md`
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## FrontendDev 任务清单
|
## 阶段划分
|
||||||
|
|
||||||
- [x] [Done: council/FrontendDev] **Task 1**: 读取 `ticket_detail.html`，分析前端构建规格项的过程
|
|
||||||
- [x] [Done: council/FrontendDev] **Task 2**: 当模板不存在时，前端如何处理 `template_snapshot` 和 `spec_base_id_map`？
|
|
||||||
- [x] [Done: council/FrontendDev] **Task 3**: `loadSoldSeats()` 函数实际实现了吗？soldSeats 数据如何填充？
|
|
||||||
- [x] [Done: council/FrontendDev] **Task 4**: 编辑模式下（已有 vr_goods_config），前端是否正确处理已删除场馆的旧规格？
|
|
||||||
- [x] [Done: council/FrontendDev] **Task 5**: 给出前端根因分析（含具体文件路径和行号）
|
|
||||||
- [x] [Done: council/FrontendDev] **Task 6**: 给出修复方案
|
|
||||||
- [x] [Done: council/FrontendDev] **Task 7**: 将调研报告写入 `reviews/council-ghost-spec-FrontendDev.md`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## SecurityEngineer 任务清单
|
|
||||||
|
|
||||||
- [x] [Done: council/SecurityEngineer] **Task S1**: 读取 AdminGoodsSaveHandle.php — 安全审计：保存时是否拒绝脏数据
|
|
||||||
- [x] [Done: council/SecurityEngineer] **Task S2**: 读取 SeatSkuService.php — 幽灵 spec 注入路径分析
|
|
||||||
- [x] [Done: council/SecurityEngineer] **Task S3**: 读取 AdminGoodsSave.php — ShopXO 入口安全检查
|
|
||||||
- [x] [Done: council/SecurityEngineer] **Task S4**: 输出安全审计报告 → `reviews/SecurityEngineer-GHOST_SPEC_SECURITY.md`
|
|
||||||
- [x] [Done: council/SecurityEngineer] **Task S5**: 更新 `reviews/council-ghost-spec-summary.md`
|
|
||||||
|
|
||||||
### 优先级定义
|
|
||||||
|
|
||||||
| 级别 | 含义 |
|
|
||||||
|------|------|
|
|
||||||
| **P1** | 安全漏洞：脏数据注入、XSS、权限绕过、数据覆盖 |
|
|
||||||
| **P2** | 功能缺陷：用户体验问题、错误提示不友好 |
|
|
||||||
| **P3** | 改进建议：代码健壮性优化 |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## BackendArchitect 任务清单
|
|
||||||
|
|
||||||
- [x] [Done: council/BackendArchitect] **Task B1**: AdminGoodsSaveHandle.php 全链路追踪 — vr_goods_config 读取/解析/snapshot 重建
|
|
||||||
- [x] [Done: council/BackendArchitect] **Task B2**: spec_base_id_map 如何被转换成规格项（已验证：存储在模板表，与幽灵 spec 无关）
|
|
||||||
- [x] [Done: council/BackendArchitect] **Task B3**: SeatSkuService GetGoodsViewData 模板不存在时的 fallback（单模板处理，多模板有缺陷）
|
|
||||||
- [x] [Done: council/BackendArchitect] **Task B4**: 幽灵 spec 产生环节 + 清理时机（保存时未清理，写回 DB）
|
|
||||||
- [x] [Done: council/BackendArchitect] **Task B5**: 商品保存规格去重逻辑（GoodsService.php:1859）
|
|
||||||
- [x] [Done: council/BackendArchitect] **Task B6**: 根因分析报告（含行号）→ `reviews/council-ghost-spec-BackendArchitect.md`
|
|
||||||
- [x] [Done: council/BackendArchitect] **Task B7**: 将调研报告写入 `reviews/council-ghost-spec-BackendArchitect.md`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 阶段划分 ✅
|
|
||||||
|
|
||||||
| 阶段 | 内容 | 状态 |
|
| 阶段 | 内容 | 状态 |
|
||||||
|------|------|------|
|
|------|------|------|
|
||||||
| **Draft** | Task 1-7（FrontendDev）+ Task S1-S3 + Task B1-B6（并行）| ✅ 完成 |
|
| **Round 1 Draft** | 安全审计 + 评估报告 | ✅ 完成 |
|
||||||
| **Review** | Task 7 + Task S4 + Task B7（输出各自报告）| ✅ 完成 |
|
| **Round 1 Review** | 投票 + 报告写入 main | 🔄 进行中 |
|
||||||
| **Finalize** | Task S5：汇总到 `reviews/council-ghost-spec-summary.md` | ✅ 完成 |
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 根因结论
|
## 安全评估结论摘要
|
||||||
|
|
||||||
| 优先级 | 根因 | 文件:行号 |
|
| # | 问题 | 严重性 | 状态 |
|
||||||
|--------|------|-----------|
|
|---|------|--------|------|
|
||||||
| **P1（功能）** | 无效 config 块未从数组移除，`continue` 后脏数据写回 DB | AdminGoodsSaveHandle.php:88-89 + 148-150 |
|
| S-1 | issueTicket() 并发竞态（无悲观锁） | **P0 建议** | 建议加唯一索引 `(order_id, seat_info)` |
|
||||||
| **P2** | GetGoodsViewData 单模板模式，多模板时覆盖有效块 | SeatSkuService.php:368 + 386-388 |
|
| S-2 | QR Secret 硬编码 fallback | **P1** | 需确认生产环境 `.env` 配置 |
|
||||||
| **P3** | BatchGenerate 对无效 template_id 返回 code=-2，阻断保存 | AdminGoodsSaveHandle.php:164-170 |
|
| S-3 | FOR UPDATE SKIP LOCKED 概念混淆 | **P2** | 防超卖依赖ShopXO原子UPDATE已有效 |
|
||||||
| **P4** | 前端过滤后 configs 为空时用户无声失去配置 | AdminGoodsSave.php:196-229 |
|
| S-4 | onOrderPaid 无事务包装 | **P2** | 可接受（有幂等保护） |
|
||||||
| **P5** | loadSoldSeats 未实现（TODO 注释） | ticket_detail.html:375-383 |
|
| S-5 | 前端XSS（观演人渲染） | **P3** | 需确认渲染方式 |
|
||||||
| **安全评估** | 无 P1 安全漏洞，属于 P2 功能缺陷 | SecurityEngineer-GHOST_SPEC_SECURITY.md |
|
|
||||||
|
**无 P0 安全漏洞。支付链路整体安全，建议持续改进。**
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 关键文件
|
## 投票
|
||||||
|
|
||||||
| 文件 | 关注点 |
|
**议题：下一步主攻方向**
|
||||||
|------|--------|
|
**投票：C（双线并行）**
|
||||||
| `shopxo/app/plugins/vr_ticket/hook/AdminGoodsSaveHandle.php` | P1 根因：continue 不删除脏 config |
|
|
||||||
| `shopxo/app/plugins/vr_ticket/service/SeatSkuService.php` | GetGoodsViewData：P2 根因，多模板处理缺陷 |
|
|
||||||
| `shopxo/app/plugins/vr_ticket/hook/AdminGoodsSave.php` | 前端过滤逻辑：P4 体验问题 |
|
|
||||||
| `shopxo/app/plugins/vr_ticket/admin/Admin.php` | VenueDelete：硬删除逻辑（第 888 行） |
|
|
||||||
| `shopxo/app/plugins/vr_ticket/view/goods/ticket_detail.html` | loadSoldSeats 未实现（P5） |
|
|
||||||
| `shopxo/app/service/GoodsService.php` | 规格列值去重检测（第 1859 行） |
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 修复方案
|
## 关键文件索引
|
||||||
|
|
||||||
### P1 Fix（立即实施）
|
| 文件 | 行号 | 安全关注点 |
|
||||||
1. AdminGoodsSaveHandle.php:88 — `continue` 改为 `unset($configs[$i])`
|
|------|------|-----------|
|
||||||
2. AdminGoodsSaveHandle.php:145 后 — 添加 `$configs = array_values($configs);`
|
| `shopxo/app/plugins/vr_ticket/service/TicketService.php` | 159-169 | issueTicket() 幂等检查（无悲观锁） |
|
||||||
3. AdminGoodsSaveHandle.php:148 — 写回前加 `if (!empty($configs))`
|
| `shopxo/app/plugins/vr_ticket/service/TicketService.php` | 252-256 | verifyTicket() FOR UPDATE |
|
||||||
4. AdminGoodsSaveHandle.php:158-173 — BatchGenerate 前增加模板存在性显式校验
|
| `shopxo/app/plugins/vr_ticket/service/TicketService.php` | 25-138 | onOrderPaid 回调 |
|
||||||
|
| `shopxo/app/plugins/vr_ticket/service/BaseService.php` | 302-303 | QR Secret 硬编码 fallback |
|
||||||
### P2 Fix（高优先级）
|
| `shopxo/app/service/BuyService.php` | 1650-1684 | ShopXO 原子条件库存扣减 |
|
||||||
1. SeatSkuService.php GetGoodsViewData — 遍历所有有效配置块，不只处理 `$vrGoodsConfig[0]`
|
| `docs/council-eval-securityengineer.md` | — | 完整安全评估报告 |
|
||||||
2. 修改 DB 写回逻辑为写回 `validConfigs` 而非 `[$config]`
|
|
||||||
|
|
||||||
### P3 Fix（中优先级）
|
|
||||||
1. AdminGoodsSave.php — configs 为空时提示用户重新选择场馆
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue