-
Notifications
You must be signed in to change notification settings - Fork 329
Closed
Feature
Copy link
Labels
in: fitIssues in FIT modulesIssues in FIT modulestype: enhancementA general enhancementA general enhancement
Milestone
Description
功能概述
为 FIT Framework 的 HTTP 客户端添加全面的鉴权支持,通过 @requestauth 注解提供多种鉴权方式的声明式配置能力
问题描述
当前现状
FIT Framework 的 HTTP 客户端缺乏统一的鉴权机制,开发者需要手动处理各种认证场景:
- 手动设置 Authorization 头
- 处理不同类型的认证(Bearer、Basic、API Key等)
- 缺乏动态鉴权支持
- 没有统一的鉴权配置方式
业务需求
在企业级应用中,HTTP 客户端调用经常需要鉴权:
- 微服务间调用需要 JWT Token 认证
- 第三方 API 调用需要 API Key 认证
- 内部服务可能需要 Basic 认证
- 复杂场景需要自定义签名算法
痛点
- 代码重复:每个客户端接口都需要重复的鉴权代码
- 维护困难:鉴权逻辑分散在各处,难以统一管理
- 扩展性差:新增鉴权类型需要修改大量代码
- 配置复杂:缺乏声明式的配置方式
解决方案
核心设计
实现基于注解的声明式 HTTP 客户端鉴权系统:
1. @requestauth 注解
- 支持接口、方法、参数三个级别
- 优先级:参数级 > 方法级 > 接口级
- 支持重复注解,处理多种鉴权场景
2. 多种鉴权类型
- BEARER: JWT Token 等 Bearer 认证
- BASIC: 用户名/密码基础认证
- API_KEY: API 密钥认证(Header/Query/Cookie)
- CUSTOM: 自定义鉴权逻辑
3. 灵活配置方式
- 静态配置: 编译时指定固定值
- 动态配置: 通过 AuthProvider 运行时获取
- 参数驱动: 方法参数直接作为鉴权信息
4. 架构组件
AuthType枚举:定义鉴权类型AuthProvider接口:动态鉴权提供器RequestAuthResolver:注解解析器AuthDestinationSetter:请求鉴权设置器StaticAuthApplier:静态鉴权应用器
使用示例
// 接口级 Bearer Token
@RequestAuth(type = AuthType.BEARER, provider = TokenProvider.class)
public interface ApiClient {
// 方法级 API Key
@RequestAuth(type = AuthType.API_KEY, name = "X-API-Key", value = "key123")
User getUser(Long userId);
// 参数级动态认证
User login(@RequestAuth(type = AuthType.BASIC) String credentials);
}技术实现
- 扩展现有 HTTP 客户端代理机制
- 与 Authorization 系统无缝集成
- 支持多级注解解析和优先级处理
- 提供完整的测试用例和文档
替代方案
方案对比
1. 手动鉴权(现状)
- ✅ 灵活性最高
- ❌ 代码重复多,维护成本高
- ❌ 缺乏统一规范
2. 配置文件方式
- ✅ 集中配置
- ❌ 缺乏类型安全
- ❌ 难以处理动态场景
3. 拦截器方式
- ✅ 统一处理
- ❌ 配置复杂,难以区分不同接口需求
- ❌ 缺乏声明式特性
4. 注解方式(推荐)
- ✅ 声明式,易于理解和维护
- ✅ 类型安全,编译时检查
- ✅ 支持多级配置和优先级
- ✅ 扩展性好,易于添加新鉴权类型
- ✅ 与现有框架设计理念一致
实现状态
此功能已在 PR #325 中完成实现,包括:
- 完整的注解和架构组件
- 详细的使用文档和测试用例
- 批量测试脚本
- 多种鉴权场景的示例代码
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
in: fitIssues in FIT modulesIssues in FIT modulestype: enhancementA general enhancementA general enhancement