huangzhenpc
|
d274c8cb14
|
feat: 品牌重命名 Sub2API -> TianShuAPI
CI / test (push) Has been cancelled
CI / golangci-lint (push) Has been cancelled
- 前端: 所有界面显示、i18n 文本、组件中的品牌名称
- 后端: 服务层、设置默认值、邮件模板、安装向导
- 数据库: 迁移脚本注释
- 保持功能完全一致,仅更改品牌名称
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
|
2026-01-04 17:50:29 +08:00 |
|
IanShaw027
|
ecfad788d9
|
feat(全栈): 实现简易模式核心功能
**功能概述**:
实现简易模式(Simple Mode),为个人用户和小团队提供简化的使用体验,隐藏复杂的分组、订阅、配额等概念。
**后端改动**:
1. 配置系统
- 新增 run_mode 配置项(standard/simple)
- 支持环境变量 RUN_MODE
- 默认值为 standard
2. 数据库初始化
- 自动创建3个默认分组:anthropic-default、openai-default、gemini-default
- 默认分组配置:无并发限制、active状态、非独占
- 幂等性保证:重复启动不会重复创建
3. 账号管理
- 创建账号时自动绑定对应平台的默认分组
- 如果未指定分组,自动查找并绑定默认分组
**前端改动**:
1. 状态管理
- authStore 新增 isSimpleMode 计算属性
- 从后端API获取并同步运行模式
2. UI隐藏
- 侧边栏:隐藏分组管理、订阅管理、兑换码菜单
- 账号管理页面:隐藏分组列
- 创建/编辑账号对话框:隐藏分组选择器
3. 路由守卫
- 限制访问分组、订阅、兑换码相关页面
- 访问受限页面时自动重定向到仪表板
**配置示例**:
```yaml
run_mode: simple
run_mode: standard
```
**影响范围**:
- 后端:配置、数据库迁移、账号服务
- 前端:认证状态、路由、UI组件
- 部署:配置文件示例
**兼容性**:
- 简易模式和标准模式可无缝切换
- 不需要数据迁移
- 现有数据不受影响
|
2025-12-29 03:24:15 +08:00 |
|
yangjianbo
|
fd51ff6970
|
fix: 代码的核心问题是判错条件用错了层级:
- apiKeyService.GetByKey(...) 返回的“找不到 API key”在这个项目里通常会被翻译成业务错误(比如
service.ErrApiKeyNotFound 这类 ApplicationError),而不是直接把 gorm.ErrRecordNotFound 透传到中
间件层。
- 因此你在中间件里用 errors.Is(err, gorm.ErrRecordNotFound) 去判断“无效 key”,很容易匹配不到(尤其
是:后面加 Redis 缓存、换存储实现、或测试里用 stub repo 时,根本不会出现 gorm 的错误)。
- 匹配不到时就会走到 500 Failed to validate API key,导致无效 API key 被错误地当成服务端故障返回
500(应该是 401)。
修复思路:中间件不要依赖 gorm 的错误,改成判断业务层错误,例如:
if errors.Is(err, service.ErrApiKeyNotFound) {
abortWithGoogleError(c, 401, "Invalid API key")
return
}
如果你把 GetByKey 的“not found”统一封装成业务错误,这样才不会被底层实现(gorm/redis/mock)影响。
|
2025-12-28 14:34:05 +08:00 |
|
IanShaw
|
cf8a64528c
|
fix: 修复 Gemini API 认证和 /responses 端点路由问题 (#45)
* fix(middleware): 修复 Gemini API Key 认证中间件用户上下文类型错误
修复了 ApiKeyAuthWithSubscriptionGoogle 中间件中设置用户上下文时的类型错误。
**问题:**
- 中间件直接设置 `apiKey.User` 对象到上下文
- 导致 handler 中获取 `AuthSubject` 时类型断言失败
- 所有 Gemini v1beta 端点返回 500 "User context not found"
**修复:**
- 改为设置 `AuthSubject` 结构体,与 `api_key_auth.go` 保持一致
- 添加 `ContextKeyUserRole` 设置以完整支持角色检查
**影响范围:**
- Gemini v1beta API 端点 (generateContent, streamGenerateContent)
- 使用 Google API Key 认证的所有请求
**测试:**
- 验证 Gemini CLI 调用成功返回 200
- 确认用户上下文正确传递到 handler
* fix(web): 修复 /responses 端点被前端中间件拦截的问题
- 将 /responses 路径添加到 API 白名单,防止其被当作前端路由处理
- 修复 /responses 端点返回 HTML 而非 API 响应的 BUG
- 解决 codex CLI stream 在远程服务器上断开连接的问题
根本原因:
在 6c469b4 提交中添加了 /responses 路由,但未同步更新前端嵌入中间件
的 API 白名单,导致该路由被拦截并返回 index.html 而非 API 响应。
|
2025-12-27 10:50:15 +08:00 |
|
ianshaw
|
9780f0fd9d
|
fix(backend): 修复 rebase 后的代码集成问题
- 更新 middleware import 路径到 internal/server/middleware
- 修复 api_key_auth_google.go 使用正确的 service 类型
- 更新 router.go 和 http.go 支持 Gemini v1beta 路由
- 在 routes/gateway.go 中添加 Gemini v1beta API 端点
- 在 routes/admin.go 中添加 Gemini OAuth 路由
- 更新 wire.go 添加 GeminiOAuthService cleanup
- 重新生成 wire_gen.go
|
2025-12-26 00:17:55 -08:00 |
|
ianshaw
|
50734c5edc
|
feat(backend): 添加 Google API Key 认证中间件
- 新增 api_key_auth_google.go: 支持 x-goog-api-key 格式认证
- 更新 api_key_auth.go: 适配 Gemini 原生 API 格式
|
2025-12-26 00:11:03 -08:00 |
|