[fit] Critical: Parameter-Applier count mismatch in HttpInvocationHandler causes potential ArrayIndexOutOfBoundsException

@requestauth

Bug 概述

HttpInvocationHandler 中参数数量与应用器数量不匹配，导致潜在的数组越界风险

问题描述

发现过程

在PR #325 实现 HTTP 客户端认证功能时，发现了一个潜在的架构问题：

HttpInvocationHandler.invoke() 方法期望参数数量与应用器数量严格一一对应
新增的静态鉴权应用器破坏了这个对应关系
理论上应该触发 ArrayIndexOutOfBoundsException，但测试暂时没有失败

问题位置

1. HttpInvocationHandler.java 第69-71行

if (args.length != appliers.size()) {
    throw new HttpClientException("Args length not equals to appliers size.");
}

2. HttpInvocationHandler.java 第81-83行

for (int i = 0; i < appliers.size(); i++) {
    appliers.get(i).apply(requestBuilder, args[i]); // 潜在数组越界
}

3. AnnotationParser.java 添加额外应用器

第110-112行：添加类级别鉴权应用器
第125-126行：添加方法级别鉴权应用器

具体分析

问题场景1：无参数方法

@RequestAuth(type = AuthType.API_KEY, name = "X-Service-Key", value = "service-key") // 类级别
public interface TestClient {
    @RequestAuth(type = AuthType.BEARER, value = "bearer-token") // 方法级别
    @GetMapping("/test")
    String test(); // 0个参数
}

应用器分析：

类级别鉴权应用器：1个
方法级别鉴权应用器：1个
参数应用器：0个
总计：2个应用器，但参数数量为0

预期行为：

第69行检查：0 != 2 → 应该抛出 HttpClientException
如果通过检查，第82行：args[0] → 应该抛出 ArrayIndexOutOfBoundsException

问题场景2：有参数方法

@RequestAuth(type = AuthType.API_KEY, name = "X-Service-Key", value = "service-key") // 类级别
public interface TestClient {
    @GetMapping("/test")
    String test(@RequestAuth(type = AuthType.BEARER) String token); // 1个参数，带鉴权注解
}

应用器分析：

类级别鉴权应用器：1个
方法级别鉴权应用器：0个
参数应用器：1个（包含@requestauth的参数）
总计：2个应用器，但参数数量为1

预期行为：

第69行检查：1 != 2 → 应该抛出 HttpClientException
如果通过检查，第82行当i=1时：args[1] → 应该抛出 ArrayIndexOutOfBoundsException

当前状态

新功能的测试用例包含了上述场景
测试执行时没有报错
功能表现正常

重现步骤

检出分支 fit-enhancement-http-client2

运行测试：

cd examples/fit-example/07-http-client-proxy
mvn test

或启动服务器并运行测试脚本：

mvn spring-boot:run -pl plugin-http-server &
./run_tests.sh

预期行为

根据 HttpInvocationHandler 的设计，应该在参数数量与应用器数量不匹配时抛出异常。

实际行为

测试正常执行，没有抛出预期的异常。

影响分析

潜在风险

数组越界风险：如果问题未被检测到，可能在特定条件下触发运行时异常
架构不一致：破坏了参数-应用器一一对应的设计原则
维护困难：未来添加新功能时可能遇到同样的问题
测试盲区：当前测试可能没有覆盖到真实的执行路径

紧急程度

优先级：高
原因：涉及核心架构的一致性和运行时稳定性

需要调查的问题

根因分析：为什么测试没有触发预期的异常？
- 是否存在其他代码路径绕过了检查？
- 是否有异常被捕获并忽略？
- 是否存在JVM级别的保护机制？
影响范围：这个问题是否影响其他现有功能？
修复策略：如何在不破坏现有功能的前提下修复这个问题？

环境信息

分支：fit-enhancement-http-client2
相关文件：
- HttpInvocationHandler.java
- AnnotationParser.java
- StaticAuthApplier.java
测试用例：TestAuthClient.java

标签建议

type: bug
in: fit
priority: high
theme: architecture

@requestauth

🔍 根因调查完成

经过深入调查，已完全确定问题的根本原因和修复方案。

📋 问题根因

1. NullPointerException 问题

触发条件: 调用无参数方法时（如 testBearerStatic()）
根本原因: Java反射机制在调用无参数方法时传递 args = null
失败位置: HttpInvocationHandler.java:69 - args.length 访问null对象
错误信息: "Cannot read the array length because \"args\" is null"

2. 参数数量不匹配问题

触发条件: 调用有参数方法时（如 testBearerDynamic(String token)）
根本原因: 静态鉴权应用器与参数应用器混合在同一列表中
失败位置: HttpInvocationHandler.java:69 - 参数数量检查
错误信息: "Args length not equals to appliers size."

🧪 验证测试结果

通过实际测试验证了问题存在：

# 无参数方法测试
curl "http://localhost:8080/http-client/auth-test?method=bearerStatic"
# 结果: 500 - "Cannot read the array length because \"args\" is null"

# 有参数方法测试
curl "http://localhost:8080/http-client/auth-test?method=bearerDynamic&token=test-token"
# 结果: 500 - "Args length not equals to appliers size."

📊 应用器数量分析

`testBearerStatic()` 方法：

类级别鉴权应用器：1个 (StaticAuthApplier)
方法级别鉴权应用器：1个 (StaticAuthApplier)
参数应用器：0个（无参数）
总应用器数：2个，参数数：0个 → 数量不匹配

`testBearerDynamic(String token)` 方法：

类级别鉴权应用器：1个 (StaticAuthApplier)
方法级别鉴权应用器：0个（方法无@requestauth）
参数应用器：1个 (MultiDestinationsPropertyValueApplier，包含@requestauth)
总应用器数：2个，参数数：1个 → 数量不匹配

🏗️ 架构设计缺陷

问题的根本原因是架构设计上的缺陷：

混合职责: 将静态应用器（不需要参数）与参数应用器（需要参数）放在同一列表
假设失效: HttpInvocationHandler 假设应用器数量等于参数数量
防护缺失: 未处理 args 为 null 的边界情况

🛠️ 修复方案

推荐采用分离应用器架构方案：

核心思路

分离数据结构: staticAppliers + paramAppliers
分离执行逻辑: 先执行静态应用器，再执行参数应用器
空值防护: 处理 args 为 null 的情况

主要修改

HttpInfo: 添加 staticAppliers 和 paramAppliers 字段
HttpInvocationHandler: 分离应用器执行逻辑，添加空值检查
AnnotationParser: 分别构建静态应用器和参数应用器列表

📋 后续计划

✅ 根因调查 - 已完成
🔄 实施修复 - 进行中
⏳ 测试验证 - 待开始
⏳ 代码审查 - 待开始

💡 预防措施

为避免类似问题，建议：

职责分离: 不同性质的组件应分离管理
边界检查: 加强对null值和边界条件的处理
单元测试: 增加对边界情况的测试覆盖

状态: 根因调查完成，正在实施修复方案。

✅ 问题已修复并验证

🔧 实施的修复方案

采用了分离应用器架构方案，完全解决了参数-应用器数量不匹配的问题：

1. HttpInfo 数据结构修改

新增 staticAppliers 字段：存储静态鉴权应用器（不需要参数）
新增 paramAppliers 字段：存储参数应用器（与参数一一对应）
保持 appliers 字段：向后兼容

2. HttpInvocationHandler 执行逻辑重构

空值防护：处理 args 为 null 的情况
分离执行：先执行静态应用器，再执行参数应用器
精确检查：只检查参数数量与参数应用器数量的匹配

3. AnnotationParser 构建逻辑优化

分离构建：分别构建静态应用器和参数应用器列表
职责清晰：类级别和方法级别鉴权归入静态应用器

🧪 验证结果

所有关键测试场景都已通过：

测试1：无参数方法

curl "http://localhost:8080/http-client/auth-test?method=bearerStatic"
# 修复前: ❌ "Cannot read the array length because \"args\" is null"
# 修复后: ✅ "Bearer Static Auth: Bearer static-bearer-token-12345"

测试2：有参数方法

curl "http://localhost:8080/http-client/auth-test?method=bearerDynamic&token=test-token"
# 修复前: ❌ "Args length not equals to appliers size."
# 修复后: ✅ "Bearer Dynamic Auth: Bearer test-token"

测试3：其他认证类型

✅ Basic 认证：正常工作
✅ API Key 认证：正常工作
✅ 组合认证：基础功能正常

📊 影响分析

优势

架构清晰：静态应用器与参数应用器职责分离
类型安全：编译时就能确定应用器类型
向后兼容：现有代码无需修改
扩展性好：未来添加新功能不会再遇到类似问题

风险控制

保持了原有 appliers 字段的向后兼容性
所有现有功能继续正常工作
新架构是增量式的，不会破坏现有代码

🎯 提交信息

Commit: 0b3b9759 - "fix: Resolve parameter-applier mismatch in HTTP client authentication"

修改文件:

HttpInfo.java: 添加分离的应用器字段
HttpInvocationHandler.java: 重构执行逻辑，添加空值防护
AnnotationParser.java: 分离应用器构建逻辑

🔮 后续改进建议

虽然当前修复已完全解决问题，但可以考虑：

完善 AuthProvider 支持：当前显示 "AuthProvider support is not implemented"
增加单元测试：为边界情况添加测试覆盖
性能优化：评估分离架构的性能影响

状态: ✅ 已修复并验证 - 问题完全解决，功能正常工作

fix: Resolve parameter-applier mismatch in HTTP client authentication

@requ…

[fit] Add comprehensive HTTP client authentication support with @requ…

[fit] Critical: Parameter-Applier count mismatch in HttpInvocationHandler causes potential ArrayIndexOutOfBoundsException #328

Description