Dify 应用用户隔离与会话管理技术方案-开发者社区

1. 方案背景与目标

背景：本项目采用 Dify 作为 LLM 能力后端（BaaS），前端通过调用 API 获取 AI 响应。

目标：

用户隔离：确保不同用户的数据（上下文、记忆、变量）严格隔离，互不可见。
安全性：防止恶意用户伪造身份获取他人对话记录。
隐私保护：避免将用户的敏感真实身份信息（如手机号、明文 ID）直接暴露给 Dify 端。

2. 总体架构设计

采用Backend-For-Frontend (BFF) / 代理模式。

严禁前端直接调用 Dify API。所有的请求必须经过业务后端（Business Backend）进行鉴权和参数注入。

2.1 交互时序图

Code snippet

sequenceDiagram participant User as 客户端 (App/Web) participant Backend as 业务后端 (Your Server) participant Dify as Dify API Service User->>Backend: 1. 发起对话请求 (携带 Token, Query) Note right of User: Header: Authorization: Bearer <token> Backend->>Backend: 2. 鉴权 (Validate Token) Backend->>Backend: 3. 解析 UserID (e.g., 10086) Backend->>Backend: 4. 生成 Dify User 标识 (Hash/UUID) Backend->>Dify: 5. 调用 /chat-messages Note right of Backend: Body: { query: "...", user: "hashed_10086" } Dify-->>Backend: 6. 返回流式/阻塞响应 Backend-->>User: 7. 转发响应给客户端

3. 详细实现逻辑

3.1 核心字段定义

在调用 Dify API 时，需重点关注以下两个字段的生命周期管理：

字段名	来源	作用	管理策略
`user`	业务后端生成	用户隔离的唯一凭证。Dify 依此区分上下文归属。	强制覆盖。由后端根据 Token 解析出的用户 ID 映射生成，禁止前端直接传递此参数。
`conversation_id`	Dify 返回	会话隔离凭证。区分同一个用户下的不同聊天窗口。	前端维护。前端存储在本地，发起请求时透传给后端，后端透传给 Dify。

3.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.3 接口开发规范

A. 客户端 -> 业务后端 (Request)

前端只需关注业务逻辑，无需关心 Dify 的底层实现。

HTTP

POST /api/ai/chat Authorization: Bearer <JWT_TOKEN> Content-Type: application/json { "query": "帮我写一个Python脚本", "conversation_id": "53006d08-...", // 如果是新会话，传 null 或空字符串 "file_url": "..." // (可选) 图片/文件上传逻辑 }

B. 业务后端 -> Dify API (Proxy Request)

后端负责“注入”身份信息。

HTTP

POST 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": [] }

4. 会话管理逻辑 (Session Handling)

4.1 开启新会话 (New Chat)

前端动作：用户点击“新建聊天”。
前端请求：调用接口时，conversation_id设为null。
Dify 行为：识别到空 ID，创建一个新会话，并在响应中返回新的conversation_id。
前端处理：接收到响应中的conversation_id，更新本地状态（URL 参数或 State）。

4.2 历史记录回溯 (History)

如果需要在前端展示历史对话列表：

Dify 接口：调用GET /conversations。
后端中转：同样需要后端代理，并在 URL 参数中附加user=hmac_u8832_x992。
隔离效果：Dify 只会返回该user标识下的历史会话列表。

5. 安全与异常处理

5.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, json=payload)