PingChuan
|
c94cc00138
|
feat:前端新增初版知识库管理页面
|
2025-11-30 19:27:01 +08:00 |
|
PingChuan
|
9614899171
|
feat:重构dify前端组件以及转发逻辑
|
2025-11-30 16:24:35 +08:00 |
|
TanWenyan
|
79e0f542be
|
回滚:客户端调用Remix API routes,避免CORS问题
问题分析:
直接让客户端调用FastAPI后端会遇到:
1. CORS跨域限制
2. Cookie无法在跨域情况下传递
3. 安全性降低
正确架构(三层代理):
浏览器 → Remix /api/* → FastAPI /dify/* → Dify
流程说明:
1. 浏览器:fetch('/api/chat-messages', { credentials: 'include' })
- 相对路径,同域请求,无CORS问题
- Cookie自动携带
2. Remix API routes (app/routes/api.chat-messages.tsx)
- 从session获取JWT
- 调用 difyClient.createChatMessage(..., jwt)
3. dify-client.server.ts
- 使用 API_BASE_URL (根据端口配置)
- 调用 FastAPI: http://baseUrl/dify/chat-messages
- 携带JWT: Authorization: Bearer {jwt}
4. FastAPI /dify 路由
- 验证JWT,提取username
- 调用Dify: http://nas.7bm.co:12980/v1/chat-messages
baseUrl配置(服务端使用):
- 端口51703 → http://172.16.0.55:8073
- 端口51704 → http://10.79.97.17:8001
- ...
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
2025-10-30 14:49:54 +08:00 |
|
TanWenyan
|
679fa31ce3
|
重构:客户端直接调用FastAPI后端,不再通过Remix中转
架构变更:
旧架构:浏览器 → Remix /api/* → dify-client.server → FastAPI /dify → Dify
新架构:浏览器 → FastAPI /dify/* → Dify
修改:
1. app/config/chat.ts
- getApiBaseUrl() 根据端口映射返回FastAPI后端地址
- 端口映射表:
* 51703 → http://172.16.0.55:8073
* 51704 → http://10.79.97.17:8001
* 51705 → http://10.79.97.17:8002
* 51706 → http://10.79.97.17:8003
* 51707 → http://10.79.97.17:8004
* 51708 → http://10.79.97.17:8005
- API_URL: `${baseUrl}/dify`
示例(端口51703):
- 浏览器Network: http://172.16.0.55:8073/dify/chat-messages
- 不再经过Remix API routes
注意:
- 需要FastAPI配置CORS允许跨域
- Cookie需要在跨域情况下正确传递
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
2025-10-30 14:44:49 +08:00 |
|
TanWenyan
|
215ecff41d
|
修复:恢复CHAT_CONFIG.APP_ID和API_KEY字段,解决"应用配置不正确"错误
问题:移除APP_ID和API_KEY后,chat/index.tsx第125行检查失败,
导致显示"应用暂时不可用,应用配置不正确"
修改:
1. app/config/chat.ts
- 添加 APP_ID = 'docreview-chat' (用于localStorage key)
- 添加 API_KEY = '' (空值,保持兼容性)
- 说明:API_KEY不再用于直接调用Dify,服务端通过JWT处理
2. app/components/chat/index.tsx
- 修改hasSetAppConfig检查:从检查APP_ID和API_KEY改为只检查API_URL
- 说明:客户端现在通过Remix API routes调用,不需要验证API_KEY
调用流程保持不变:
客户端 → /api/* → JWT验证 → FastAPI /dify → Dify
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
2025-10-30 14:39:52 +08:00 |
|
TanWenyan
|
cf6e9c2421
|
紧急修复:客户端改为调用Remix API routes,不再直接调用Dify API
根本问题:客户端代码直接调用Dify API(12980端口),绕过了服务端代理
修改内容:
1. app/config/api-config.ts
- 添加独立的 difyBaseUrl 配置(指向外网 nas.7bm.co:8000)
- 导出 DIFY_BASE_URL 供服务端使用
2. app/config/chat.ts
- 移除直接Dify API配置(NEXT_PUBLIC_API_URL, APP_ID, API_KEY)
- 移除 generateUserId 函数
- API_URL 改为 '/api'(指向Remix API routes)
3. app/services/api.client.ts
- 所有fetch调用改为相对路径 /api/*
- 移除所有 Authorization 头(服务端自动处理JWT)
- 移除所有 user 参数传递(服务端从JWT提取)
- credentials 改为 'include' 以携带cookie
4. app/services/dify-client.server.ts
- 使用 DIFY_BASE_URL 替代 API_BASE_URL
5. app/utils/dify-test.client.ts
- 测试函数改为调用Remix API routes
调用链路:
客户端 → /api/* → Remix API routes → dify-client.server.ts → FastAPI /dify → Dify
解决问题:
- ✅ 不再直接调用 nas.7bm.co:12980(Dify端口)
- ✅ 统一通过 nas.7bm.co:8000/dify(FastAPI代理)
- ✅ 所有请求都经过JWT认证
- ✅ user字段由后端自动管理
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
2025-10-30 11:25:37 +08:00 |
|
PingChuan
|
6698542839
|
删除调试打印信息
|
2025-07-02 10:28:47 +08:00 |
|
pingchuan
|
ce851cc448
|
取消统一转发Dify请求,改为由客户端直接发送
|
2025-07-01 15:54:28 +08:00 |
|
pingchuan
|
af33de09db
|
基于 shiy-temp分支修改
|
2025-06-04 11:18:52 +08:00 |
|