sqlite-web 0.7.2
gitea.db
issue
Create
Query
access
access_token
action
action_artifact
action_run
action_run_index
action_run_job
action_runner
action_runner_token
action_schedule
action_schedule_spec
action_task
action_task_output
action_task_step
action_tasks_version
action_variable
app_state
attachment
auth_token
badge
branch
collaboration
comment
commit_status
commit_status_index
commit_status_summary
commit_sync_log
commit_sync_status
dbfs_data
dbfs_meta
deploy_key
email_address
email_hash
external_login_user
follow
gpg_key
gpg_key_import
hook_task
issue
issue_assignees
issue_content_history
issue_dependency
issue_index
issue_label
issue_pin
issue_user
issue_watch
label
language_stat
lfs_lock
lfs_meta_object
login_source
milestone
mirror
notice
notification
oauth2_application
oauth2_authorization_code
oauth2_grant
org_user
package
package_blob
package_blob_upload
package_cleanup_rule
package_file
package_property
package_version
project
project_board
project_issue
protected_branch
protected_tag
public_key
pull_auto_merge
pull_request
push_mirror
reaction
release
renamed_branch
repo_archiver
repo_hidden_file
repo_indexer_status
repo_license
repo_redirect
repo_topic
repo_transfer
repo_unit
repository
review
review_state
secret
session
sqlite_sequence
star
stopwatch
system_setting
task
team
team_invite
team_repo
team_unit
team_user
topic
tracked_time
two_factor
upload
user
user_badge
user_blocking
user_open_id
user_redirect
user_setting
version
watch
webauthn_credential
webhook
Toggle helper tables
Structure
Content
Query
Insert
Drop
Import
Export
Update row 250 in issue
id
Primary key.
INTEGER NOT NULL
repo_id
INTEGER
index
INTEGER
poster_id
INTEGER
original_author
TEXT
original_author_id
INTEGER
name
🔍 代码审查报告:pay-260519 - Merge remote-tracking branch 'pay/pay-260519' into
TEXT
content
## 自动代码审查报告 **分支**: pay-260519 **提交**: `1693cd0c92f774fe0768e35812c1c00e4f644e34` **提交人**: zhangjunnan (121158035@qq.com) **时间**: 2026-05-20 18:21:22 --- ## 1. 审查摘要 - **代码质量评分**:5.5 / 10 分 - **总体评价**:代码覆盖了较完整的支付、团购验券、订单计算及桌台状态流转业务,但存在**严重的密码学误用、API 响应污染、SQL 注入风险及大量重复逻辑**。财务计算未做精度控制,架构偏向过程式堆砌,可维护性与安全性亟待提升。 - **风险等级**:🔴 高 ## 2. 问题详情 | 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) | | :--- | :--- | :--- | :--- | :--- | | 🔴 严重 | `GuoTong.php` / `checksign()` | **返回值覆盖 Bug**:循环解密后拼接了 `$result`,但 `return $dataDecrypt;` 仅返回最后一次解密的片段,导致签名校验必然失败或数据截断。 | 返回累积结果 `$result`,并增加解密失败时的异常处理。 | `return $result;` | | 🔴 严重 | `GuoTong.php` / `create_sing()` | **密码学误用**:使用公钥进行“签名”(`openssl_public_encrypt`)。标准 API 签名应使用**私钥**配合 `openssl_sign()`,公钥仅用于验签。当前实现无法防篡改且不符合国密/RSA 规范。 | 改用 `openssl_sign()` 配合私钥生成签名,或确认第三方接口是否确实要求“公钥加密”(若是,应重命名方法为 `encrypt` 而非 `sign`)。 | `openssl_sign($sha256, $sign, $privateKey, OPENSSL_ALGO_SHA256);` | | 🔴 严重 | `Neworderservice.php` / ~380行 | **输出污染**:循环内存在 `echo $vip_upgrade_data_actual_pay;`,会直接破坏 JSON/XML 响应结构,导致前端解析失败或支付回调异常。 | 立即删除该 `echo` 语句,调试应使用 `do_log()` 或 CI 日志组件。 | `// 删除 echo $vip_upgrade_data_actual_pay;` | | 🔴 严重 | `Neworderservice.php` / ~320行 | **SQL 注入风险**:`$pack_goods_where = "wares_package._package_id in (" . implode(",", $id_array['package_id']) . ")";` 直接拼接数组,若 `$id_array['package_id']` 含非数字字符将导致注入。 | 使用 CI 查询构造器安全绑定参数。 | `$this->CI->db->where_in('wares_package._package_id', $id_array['package_id']);` | | 🔴 严重 | `GuoTong.php` / `request()` | **SSL 验证关闭**:`CURLOPT_SSL_VERIFYPEER` 与 `CURLOPT_SSL_VERIFYHOST` 设为 `false`,极易遭受中间人攻击(MITM),导致支付数据泄露。 | 生产环境必须开启验证,并配置正确的 CA 证书路径。 | `curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true); curl_setopt($ch, CURLOPT_CAINFO, APPPATH.'certs/ca-bundle.crt');` | | 🟠 警告 | `GuoTong.php` / `get_client_ip()` | **IP 伪造风险**:直接信任 `HTTP_CLIENT_IP` 和 `HTTP_X_FORWARDED_FOR`,攻击者可轻易伪造 IP 绕过风控或日志追踪。 | 使用 CI3 内置安全方法或严格过滤 IP 格式。 | `return $this->CI->input->ip_address();` | | 🟠 警告 | `Juhai.php` / `prepare_by_voucher_data` & `room_package_prepare` | **严重代码重复**:两个方法中套餐校验、时间交集计算、Redis 缓存逻辑重复率超 80%,违反 DRY 原则,维护成本极高。 | 抽取公共方法 `validate_and_prepare_package($merchant_id, $shop_id, $package_info, $is_voucher = true)`,差异化逻辑通过参数控制。 | *(见下方重构建议)* | | 🟠 警告 | `Neworderservice.php` / 价格计算 | **浮点数精度丢失**:大量使用 `*`、`/` 进行金额计算(如 `$goods_actual_pay * $vip_discount_rate`),PHP 浮点运算易产生 `0.000000001` 误差,导致对账不平。 | 财务计算统一使用 `bcmath` 扩展或 `round($val, 2)` 严格保留两位小数。 | `$actual = bcmul($price, $rate, 4); $actual = round($actual, 2);` | | 🟠 警告 | `Tuangou.php` / `_common_processing()` | **违反开闭原则**:巨型 `switch` 分发器耦合了抖音、美团、巨嗨等所有平台逻辑,新增平台需修改核心类,易引发回归 Bug。 | 采用**策略模式**:定义 `TuangouPlatformInterface`,各平台实现独立类,通过工厂或容器动态加载。 | `$platform = TuangouFactory::create($platform_id); $platform->prepare(...);` | | 🟡 建议 | 全局 | **缺乏类型声明与 PSR-12 规范**:方法无参数/返回值类型提示,缩进不一致,魔法数字(如 `13`, `4`, `7`, `-1`)遍布,可读性差。 | 补充 `declare(strict_types=1);`,使用 `int`, `string`, `array`, `bool` 类型声明,将魔法数字提取为 `const`。 | `public function prepare(int $merchant_id, int $shop_id, string $voucher_code): bool` | | 🟡 建议 | `GuoTong.php` / `set_config()` | **模型重复加载**:每次调用 `set_config()` 都执行 `$CI->load->model()`,增加 I/O 开销。 | 在构造函数中加载模型,或使用 CI 的 `autoload.php` 预加载。 | `public function __construct() { $this->CI =& get_instance(); $this->CI->load->model('Ahead_common_config_model'); }` | | 🟡 建议 | `Tuangou.php` / Redis 操作 | **异常静默吞没**:`catch (RedisException $e) {}` 未记录日志,缓存失败时业务无降级策略,可能导致验券状态不一致。 | 记录错误日志,并返回明确状态码供上层处理。 | `catch (RedisException $e) { log_message('error', 'Redis操作失败: '.$e->getMessage()); return false; }` | ## 3. 总结与行动建议 ### 🚨 优先修复的关键问题(P0) 1. **修复密码学与签名逻辑**:立即核实第三方 `GuoTong` 接口文档。若为签名,必须改用 `openssl_sign()` + 私钥;若为加密,请重命名方法避免歧义。修复 `checksign` 的返回值覆盖 Bug。 2. **清理输出污染**:全局搜索并移除 `Neworderservice.php` 中的 `echo` 调试语句,确保 API 响应纯净。 3. **封堵 SQL 注入**:将 `Neworderservice.php` 中的字符串拼接查询全部替换为 CI3 的 `$this->CI->db->where_in()` 或 `$this->CI->db->query($sql, $bindings)`。 4. **开启 SSL 验证**:支付类请求必须强制验证证书,配置 CA 文件路径,杜绝中间人劫持。 ### 🛠 后续重构与优化方向 1. **架构解耦(策略模式)**:`Tuangou.php` 的 `_common_processing` 是典型的过程式反模式。建议按平台拆分为 `DouyinStrategy`、`MeituanStrategy`、`JuhaiStrategy`,通过工厂类按需实例化,符合开闭原则。 2. **财务计算标准化**:建立统一的 `PriceCalculator` 工具类,内部封装 `bcmath` 运算与四舍五入规则,所有涉及金额、折扣、服务费的计算必须经过该类,避免散落各处的浮点运算。 3. **消除重复代码**:`Juhai.php` 中两个 `prepare` 方法高度相似。建议提取核心校验链(券状态 → 门店/套餐匹配 → 时间/星期交集 → Redis 缓存),通过配置数组控制差异点。 4. **规范与可测试性**: - 补充 `declare(strict_types=1);` 及 PHP 7.4+ 类型声明。 - 将魔法数字(如 `pay_platform == 7`、`status == 1`)定义为类常量或枚举。 - 为价格计算、时间交集算法编写 PHPUnit 单元测试,覆盖边界条件(如跨天、闰年、0元单、负数折扣)。 > 💡 **框架说明**:当前代码结构高度符合 **CodeIgniter 3** 规范(如 `get_instance()`、`$this->load->model()`、`BASEPATH` 守卫)。若 `phpci` 为贵司基于 CI3 的定制框架,上述建议可直接适用;若为独立框架,请确保 `load->model()` 与查询构造器行为与 CI3 一致,必要时参考 `phpci` 官方文档调整组件调用方式。 --- *此 Issue 由代码审查服务自动创建*
TEXT
milestone_id
INTEGER
priority
INTEGER
is_closed
INTEGER
is_pull
INTEGER
num_comments
INTEGER
ref
TEXT
deadline_unix
INTEGER
created_unix
INTEGER
updated_unix
INTEGER
closed_unix
INTEGER
is_locked
INTEGER NOT NULL (default 0
content_version
INTEGER NOT NULL (default 0
time_estimate
INTEGER NOT NULL (default 0
Update
Cancel