核心内容摘要
伽罗太华：一场关于泪水、信仰与不屈的史诗
方案背景与目标背景本项目采用 Dify 作为 LLM 能力后端BaaS前端通过调用 API 获取 AI 响应。
目标用户隔离确保不同用户的数据上下文、记忆、变量严格隔离互不可见。
安全性防止恶意用户伪造身份获取他人对话记录。
隐私保护避免将用户的敏感真实身份信息如手机号、明文 ID直接暴露给 Dify 端。
总体架构设计采用Backend-For-Frontend (BFF) / 代理模式。
严禁前端直接调用 Dify API。
所有的请求必须经过业务后端Business Backend进行鉴权和参数注入。
1 交互时序图Code snippetsequenceDiagram participant User as 客户端 (App/Web) participant Backend as 业务后端 (Your Server) participant Dify as Dify API Service User-Backend:
发起对话请求 (携带 Token, Query) Note right of User: Header: Authorization: Bearer token Backend-Backend:
鉴权 (Validate Token) Backend-Backend:
解析 UserID (e.g.,
Backend-Backend:
生成 Dify User 标识 (Hash/UUID) Backend-Dify:
调用 /chat-messages Note right of Backend: Body: { query: ..., user: hashed_10086 } Dify--Backend:
返回流式/阻塞响应 Backend--User:
转发响应给客户端
详细实现逻辑
1 核心字段定义在调用 Dify API 时需重点关注以下两个字段的生命周期管理字段名来源作用管理策略user业务后端生成用户隔离的唯一凭证。
Dify 依此区分上下文归属。
强制覆盖。
由后端根据 Token 解析出的用户 ID 映射生成禁止前端直接传递此参数。
conversation_idDify 返回会话隔离凭证。
区分同一个用户下的不同聊天窗口。
前端维护。
前端存储在本地发起请求时透传给后端后端透传给 Dify。
2 用户标识映射策略 (User Identity Mapping)为了保护隐私建议不要直接使用数据库的主键 ID如1或业务账号如admin建议使用Hash 加盐或UUID映射。
方案 A (推荐 - Hash映射)dify_user_id HMAC_SHA256(uid, secret_salt)优点确定性同一个用户永远生成相同的 ID方便后续统计 Token 用量且不可逆Dify 侧无法反推真实身份。
方案 B (简单 - 直接映射)dify_user_id user_ uid优点调试方便直观。
3 接口开发规范A. 客户端 - 业务后端 (Request)前端只需关注业务逻辑无需关心 Dify 的底层实现。
HTTPPOST /api/ai/chat Authorization: Bearer JWT_TOKEN Content-Type: application/json { query: 帮我写一个Python脚本, conversation_id: 53006d08-..., // 如果是新会话传 null 或空字符串 file_url: ... // (可选) 图片/文件上传逻辑 }B. 业务后端 - Dify API (Proxy Request)后端负责“注入”身份信息。
HTTPPOST https://api.dify.ai/v1/chat-messages Authorization: Bearer DIFY_APP_KEY Content-Type: application/json { inputs: {}, query: 帮我写一个Python脚本, // 来自前端 response_mode: streaming, conversation_id: 53006d08-..., // 来自前端透传 user: hmac_u8832_x992, // 【关键】由后端计算并强制注入不可被前端参数覆盖 files: [] }
会话管理逻辑 (Session Handling)
1 开启新会话 (New Chat)前端动作用户点击“新建聊天”。
前端请求调用接口时conversation_id设为null。
Dify 行为识别到空 ID创建一个新会话并在响应中返回新的conversation_id。
前端处理接收到响应中的conversation_id更新本地状态URL 参数或 State。
2 历史记录回溯 (History)如果需要在前端展示历史对话列表Dify 接口调用GET /conversations。
后端中转同样需要后端代理并在 URL 参数中附加userhmac_u8832_x992。
隔离效果Dify 只会返回该user标识下的历史会话列表。
安全与异常处理
1 身份防伪造 (Anti-Spoofing)风险点如果后端直接盲目透传前端的所有参数黑客可能在前端构造{ user: admin_id }请求。
防御在构造发往 Dify 的 Request Body 时代码必须显式重写user字段。
Python# Python 伪代码示例 payload request.json # 强制覆盖无视前端传来的 user payload[user] get_current_user_id_hash(request.user) response requests.post(dify_url, jsonpayload)
2 敏感数据过滤Dify 的日志中会记录query和response。
建议在发送给 Dify 前如果业务对隐私极其敏感可在后端增加一层 PII (个人身份信息) 过滤逻辑将手机号、身份证等正则替换为[REDACTED]。
实施 Checklist[ ]后端已实现 Token 鉴权中间件。
[ ]后端已封装 Dify Client确保所有请求自动注入user字段。
[ ]后端user字段采用了 Hash 或加密 ID未传输明文手机号。
[ ]前端已实现conversation_id的本地存储与状态管理。
[ ]运维Dify API Key 已存储在后端环境变量中未暴露在前端代码。