Skip to content

fix: [AI Agent] The same workflow functions correctly during backend debugging; however, when accessed via a web link, images fail to load during conversation, and certain nodes are missing from the execution details. #7718

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
shaohuzhang1 merged 1 commit into from
Nov 6, 2026
Merged

fix: [AI Agent] The same workflow functions correctly during backend debugging; however, when accessed via a web link, images fail to load during conversation, and certain nodes are missing from the execution details. #7718

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions apps/application/workflow/nodes/image_generate_node/image_generate_node.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -221,12 +221,13 @@ def _upload_tool_file(self, file, workflow_params):
def _upload_application_file(self, file, workflow_params):
application_id = workflow_params.get("application_id")
chat_id = workflow_params.get("chat_id")
chat_user_id = workflow_params.get("chat_user_id")
return FileSerializer(
data={
"file": file,
"meta": {"debug": False, "chat_id": chat_id, "application_id": application_id},
"source_id": application_id,
"source_type": FileSourceType.APPLICATION.value,
"meta": {"chat_id": chat_id, "application_id": application_id, "user_id": chat_user_id},
"source_id": chat_id,
"source_type": FileSourceType.CHAT.value,
}
).upload()

Expand Down
12 changes: 4 additions & 8 deletions apps/application/workflow/nodes/image_to_video_node/image_to_video_node.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -223,18 +223,14 @@ def _upload_tool_file(self, file, workflow_params):
def _upload_application_file(self, file, workflow_params):
application_id = workflow_params.get("application_id")
chat_id = workflow_params.get("chat_id")
debug = workflow_params.get("debug", False)
meta = {
"debug": debug,
"chat_id": chat_id,
"application_id": application_id,
}
chat_user_id = workflow_params.get("chat_user_id")
meta = {"chat_id": chat_id, "application_id": application_id, "user_id": chat_user_id}
file_url = FileSerializer(
data={
"file": file,
"meta": meta,
"source_id": application_id,
"source_type": FileSourceType.APPLICATION.value,
"source_id": chat_id,
"source_type": FileSourceType.CHAT.value,
}
).upload()
return file_url

@shaohuzhang1 shaohuzhang1 Nov 6, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

1. Potential issues (bugs)

  • Changed source_id/source_type semantics silently: The file is now attributed to the chat rather than the application. If any existing logic queries files by source_id = application_id with FileSourceType.APPLICATION (e.g., cleanup, permissions, display), it will break or lose access to previously-uploaded files. Verify all consumers before merging.
  • Lost debug flag: debug was removed from meta. If downstream code reads meta["debug"] (e.g., to skip persistence or apply debug behavior), this is a regression. Confirm it's now handled elsewhere; if not, keep it.
  • Missing keys are not validated: If chat_id, application_id, or chat_user_id is absent from workflow_params, None gets written into metadata/source_id silently. Add validation: 
    if not chat_id or not application_id:
    raise ValueError("application_id and chat_id are required")
  • Naming inconsistency: the param is chat_user_id but stored as user_id. Fine, but document it, since key mismatch is a common bug source.

2. Minor style/robustness

  • Consider .get() defaults for consistency: workflow_params.get("chat_user_id", "") if empty strings are preferable to None in storage.
  • The meta dict fits on one line longer than PEP8 allows; current formatting is fine, just be consistent with _upload_tool_file (which presumably should get the same user_id treatment — check for symmetry).

3. Optimization suggestions

  • Minimal, but you could avoid rebuilding the dict inline: 
    meta = {
    "chat_id": chat_id,
    "application_id": application_id,
    "user_id": chat_user_id,
}
    for readability/greppability.
  • Consider adding logging when required params are missing instead of only failing at serialization time.

Summary: No syntax problems, but the semantic change of source_id/source_type and removal of debug are behavior changes that must be verified against all consumers of this metadata.

Expand Down
7 changes: 4 additions & 3 deletions apps/application/workflow/nodes/text_to_speech_node/text_to_speech_node.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -198,12 +198,13 @@ def _upload_tool_file(self, file, workflow_params):
def _upload_application_file(self, file, workflow_params):
application_id = workflow_params.get("application_id")
chat_id = workflow_params.get("chat_id")
chat_user_id = workflow_params.get("chat_user_id")
return FileSerializer(
data={
"file": file,
"meta": {"debug": False, "chat_id": chat_id, "application_id": application_id},
"source_id": application_id,
"source_type": FileSourceType.APPLICATION.value,
"meta": {"debug": False, "chat_id": chat_id, "application_id": application_id, "user_id": chat_user_id},
"source_id": chat_id,
"source_type": FileSourceType.CHAT.value,
}
).upload()

Expand Down
12 changes: 4 additions & 8 deletions apps/application/workflow/nodes/text_to_video_node/text_to_video_node.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -186,18 +186,14 @@ def _upload_tool_file(self, file, workflow_params):
def _upload_application_file(self, file, workflow_params):
application_id = workflow_params.get("application_id")
chat_id = workflow_params.get("chat_id")
debug = workflow_params.get("debug", False)
meta = {
"debug": debug,
"chat_id": chat_id,
"application_id": application_id,
}
chat_user_id = workflow_params.get("chat_user_id")
meta = {"chat_id": chat_id, "application_id": application_id, "user_id": chat_user_id}
file_url = FileSerializer(
data={
"file": file,
"meta": meta,
"source_id": application_id,
"source_type": FileSourceType.APPLICATION.value,
"source_id": chat_id,
"source_type": FileSourceType.CHAT.value,
}
).upload()
return file_url

@shaohuzhang1 shaohuzhang1 Nov 6, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Issues & Suggestions

  1. Missing validation — application_id, chat_id, and chat_user_id are all used without checking for None. A missing chat_id (now used as source_id) could create Files with null/incorrect source linkage. Consider raising an error if they're absent:

    if not chat_id or not application_id:
    raise ValueError("chat_id and application_id are required")

  2. Semantic change of source_id — source_id changed from application_id to chat_id. If any existing logic (queries, permissions, cleanup) keys off source_id = application_id, this is a breaking change for previously uploaded files. Migration/backfill may be needed.

  3. Key mismatch: user_id vs chat_user_id — meta stores chat_user_id under "user_id". That's fine, but confirm downstream consumers expect user_id, not chat_user_id.

  4. Removed debug handling — anything relying on meta["debug"] will now get None/KeyError. Verify no caller depends on it.

  5. Hard requirement on chat_user_id — if old callers don't pass it, user_id will silently be None. Add validation or a default.

  6. Minor/style — dict literal fits fine; consider f-string consistency elsewhere. No performance concerns here; changes are trivial cost-wise.

Overall: logic looks intentional (shifting file ownership from application-level to chat-level + user attribution), but items 1–4 deserve verification before merging.

Expand Down
6 changes: 3 additions & 3 deletions apps/chat/serializers/chat_authentication.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,14 +31,14 @@ class AnonymousAuthenticationSerializer(serializers.Serializer):
def auth(self, request):
self.is_valid(raise_exception=True)
token = request.META.get("HTTP_AUTHORIZATION")
token_details = {}
token_details = None
try:
# 校验token
if token is not None:
token_details = signing.loads(token[7:])
token_details = parse_token(token[7:])
except Exception:
pass
chat_user_id = token_details.get("id") or str(uuid.uuid7())
chat_user_id = token_details.id if token_details else str(uuid.uuid7())
_type = AuthenticationType.CHAT_USER

access_token = self.data.get("access_token")
Expand Down
22 changes: 18 additions & 4 deletions apps/chat/views/v3/chat.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -456,7 +456,7 @@ def post(self, request: Request):
version, get_key = Cache_Version.CHAT_USER_TOKEN.value
auth = request.META.get("HTTP_AUTHORIZATION")
cache.delete(get_key(token=auth), version=version)
return result.success(True)
return clear_file_auth_cookie(result.success(True), request.query_params.get("accessToken"))
return result.error(_("Failed to change password"))


Expand All @@ -481,6 +481,20 @@ def get(self, request: Request):
return result.success(ChatUserProfileSerializer().profile(request.user.profile))


FILE_AUTH_COOKIE = "mk_file_auth"


def get_chat_user_cookie_path(access_token):
"""对话用户登录时写入文件凭证 cookie 的路径；退出登录时按同一路径删除。"""
return f"/chat/{access_token + '/' if access_token else ''}"


def clear_file_auth_cookie(response: HttpResponse, access_token):
"""删除对话用户登录写入的文件凭证 cookie；该 cookie 为 HttpOnly，前端无法自行清除。"""
response.delete_cookie(FILE_AUTH_COOKIE, path=get_chat_user_cookie_path(access_token), samesite="Lax")
return response


class BaseAuthView(APIView):
def create_token_and_cache(self, user, access_token, operate):
application_id = None
Expand Down Expand Up @@ -522,7 +536,7 @@ def create_token_and_cache(self, user, access_token, operate):
def generate(self, request, token: str, response: HttpResponse, path: str = "/chat"):
secure = request.is_secure()
response.set_cookie(
"mk_file_auth",
FILE_AUTH_COOKIE,
value=token,
max_age=7 * 24 * 3600,
path=path,
Expand Down Expand Up @@ -550,7 +564,7 @@ def post(self, request: Request):
user.source = "LOCAL"
token = self.create_token_and_cache(user, access_token, Operate.LOCAL)
response = result.success({"token": token})
return self.generate(request, token, response, path=f"/chat/{access_token + '/' if access_token else ''}")
return self.generate(request, token, response, path=get_chat_user_cookie_path(access_token))


class Logout(APIView):
Expand All @@ -569,4 +583,4 @@ def post(self, request: Request):
version, get_key = Cache_Version.CHAT_USER_TOKEN.value
auth = request.META.get("HTTP_AUTHORIZATION")
cache.delete(get_key(token=auth[7:]), version=version)
return result.success(True)
return clear_file_auth_cookie(result.success(True), request.query_params.get("accessToken"))

@shaohuzhang1 shaohuzhang1 Nov 6, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can only review the shown diff/surrounding lines, so I’m assuming the missing imports/settings are already correct.

Potential bugs / correctness issues

  1. Cookie deletion depends on an exact accessToken match

    • Login sets the cookie at: 
      /chat/<access_token>/
    • Logout and change-password clear it using: 
      request.query_params.get("accessToken")
    • If the query parameter is missing, empty, or different from the token used at login, delete_cookie() will use the wrong path and the HttpOnly cookie will not be deleted.
    • This is the biggest issue. Consider deriving the token from the authenticated request instead of a query parameter, e.g. from Authorization: Bearer <token>, or store the cookie path server-side.

  2. Access token in query string is risky

    • accessToken in the query string can leak via access logs, browser history, Referer headers, proxies, etc.
    • Prefer the Authorization header or server-side session/state. If backward compatibility requires the query param, validate it strictly and avoid logging it.

  3. Cache deletion inconsistency in ChangePassword

    • In change-password: 
      auth = request.META.get("HTTP_AUTHORIZATION")
cache.delete(get_key(token=auth), version=version)
    • In logout: 
      cache.delete(get_key(token=auth[7:]), version=version)
    • If get_key() expects the raw token, change-password is deleting with "Bearer <token>" instead of <token>, so the cache entry may not be removed.
    • Also, auth[7:] will raise TypeError if HTTP_AUTHORIZATION is missing. Validate authentication before slicing.

  4. Cookie deletion must match the original cookie’s domain and path

    • Browser cookie deletion requires matching name, domain, and path.
    • If generate() sets a domain, clear_file_auth_cookie() must pass the same domain.
    • secure, httponly, and samesite are not used for cookie matching, but keeping them consistent avoids confusion.

  5. Multiple path-scoped cookies may accumulate

    • Because the path contains the access token, each login with a different token can create a separate mk_file_auth cookie: 
      /chat/token-a/
/chat/token-b/
    • Logout only clears the current path. Old cookies remain until expiry.
    • If possible, use a fixed path such as /chat/ and rely on server-side validation, or explicitly clean up old paths.

  6. Raw token is embedded in the cookie path

    • Cookie paths are not a strong security boundary, and the token may contain characters that are awkward in a Set-Cookie path.
    • Prefer a fixed cookie path, or at minimum validate/encode the token and keep it reasonably bounded.

Compatibility / implementation notes

  1. delete_cookie(..., samesite="Lax") depends on Django version

    • Modern Django supports samesite in delete_cookie(), but older versions may not.
    • If the project supports older Django, verify this. Otherwise it is harmless, though not required for deletion.

  2. Ensure HttpResponse is imported

    • The new function uses HttpResponse in the annotation. If it is not imported and annotations are evaluated at runtime, this will raise NameError.

  3. clear_file_auth_cookie() assumes result.success() returns an object with delete_cookie()

    • DRF Response generally inherits from Django’s response classes and should support delete_cookie(), but if result.success() returns a custom wrapper, this will fail.
    • Consider typing it as the actual response type used by your project.

Suggested cleanup / optimization

  1. Centralize cookie set/clear logic

    • Use one helper for setting and one for clearing so path, domain, secure, httponly, and samesite cannot drift:
    def set_file_auth_cookie(response, token, path, secure):
    response.set_cookie(
        FILE_AUTH_COOKIE,
        value=token,
        max_age=7 * 24 * 3600,
        path=path,
        secure=secure,
        httponly=True,
        samesite="Lax",
    )
    return response

def clear_file_auth_cookie(response, path):
    response.delete_cookie(FILE_AUTH_COOKIE, path=path, samesite="Lax")
    return response
    • Then compute the path once and pass it to both.

  2. Prefer deriving the token from the authenticated request

    • Example, if the cache token is the Bearer token:
    auth = request.META.get("HTTP_AUTHORIZATION", "")
if not auth.startswith("Bearer "):
    return result.error(...)
access_token = auth[7:]
    • Then use access_token for both cache invalidation and cookie-path clearing. This avoids relying on a query parameter and reduces leakage.

Summary

The main functional risk is that the cookie is only cleared if accessToken is supplied correctly as a query parameter. Missing or mismatched values leave the HttpOnly cookie in place. The main security concern is putting the access token in the query string. Also fix the "Bearer " handling inconsistency in change-password and add guards for missing Authorization headers.

5 changes: 4 additions & 1 deletion apps/system_manage/serializers/chat_user_serializer.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,10 @@ def create_token_and_cache(access_token, user):
raise AppApiException(1005, _("Invalid access token"))

application_id = application_access_token.application_id
# 检查用户是否有权限访问该应用
# 如果不需要认证就直接
if not application_access_token.authentication:
return
# 检查用户是否有权限访问该应用
is_authorized = ResourceChatUserAuthorize.objects.filter(
resource_id=application_id, resource_type=ResourceType.APPLICATION.value, is_auth=True, user_id=user.id
).exists()
Expand Down
6 changes: 3 additions & 3 deletions ui/src/api/chat/auth.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -80,9 +80,9 @@ const getCaptcha = (username: string, accessToken: string) => {
return get<ChatCaptchaResponse>('/v3/captcha', { username, accessToken })
}

/** 退出当前对话用户登录状态。 */
const postLogout = () => {
return post<undefined, boolean>('/v3/auth/logout')
/** 退出当前对话用户登录状态；传入 accessToken 时后端按对应应用的路径清除文件凭证 cookie。 */
const postLogout = (accessToken?: string) => {
return post<undefined, boolean>('/v3/auth/logout', undefined, accessToken ? { accessToken } : undefined)
}

export default {
Expand Down
3 changes: 2 additions & 1 deletion ui/src/api/chat/chat-user.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,8 @@ const getChatUserProfile = () => {
}

/** 修改当前用户密码，提交 RSA 加密后的表单。 */
const postResetPassword = (data: { encryptedData: string }) => post<{ encryptedData: string }, boolean>('/v3/chat_user/current/reset_password', data)
const postResetPassword = (data: { encryptedData: string }, accessToken?: string) =>
post<{ encryptedData: string }, boolean>('/v3/chat_user/current/reset_password', data, accessToken ? { accessToken } : undefined)

/** 获取当前用户 API Key；首次读取由服务端创建。 */
const getApiKey = () => get<ChatUserApiKey>('/v3/api_key')
Expand Down
2 changes: 1 addition & 1 deletion ui/src/conversation-panel/left-sidebar/account-menu/UserPwdDialog.vue
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -58,7 +58,7 @@ async function submitPassword() {
return
}

return ChatUserApi.postResetPassword({ encryptedData })
return ChatUserApi.postResetPassword({ encryptedData }, auth.accessToken)
.then(() => {
MsgSuccess('密码修改成功')

Expand Down
7 changes: 5 additions & 2 deletions ui/src/stores/chat/auth.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -139,7 +139,7 @@ export const useChatAuthStore = defineStore('chat-auth', {

/** 退出当前场景的登录状态。 */
logout() {
return ChatAuthApi.postLogout().then(() => this.clearToken())
return ChatAuthApi.postLogout(this.accessToken).then(() => this.clearToken())
},

/** 保存指定场景的 token；是当前场景时同步到 Store。 */
Expand All @@ -158,7 +158,10 @@ export const useChatAuthStore = defineStore('chat-auth', {
useChatUserStore().clearCurrentUser()
},

/** 清除当前场景的 token，如退出登录。 */
/**
* 清除当前场景本地保存的 token，如退出登录。
* 文件凭证 cookie（mk_file_auth）为 HttpOnly，前端无法清除，由退出登录、修改密码接口的响应删除。
*/
clearToken() {
localStorage.removeItem(getTokenStorageKey(this.scope))
this.token = ''
Expand Down
Loading