langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-20 19:50:06 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

sys.userID Returns end_user.session_id Instead of accounts.id in Workflow (Dify 1.7.1, "Run" Page) #20948

New Issue
Closed
opened 2026-02-21 20:09:55 -05:00 by yindo · 2 comments
yindo commented 2026-02-21 20:09:55 -05:00
Owner
Copy Link
Copy Source

Originally created by @Zedthm on GitHub (Dec 10, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.7.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Description:
In Dify 1.7.1, when accessing workflows via the "Run" page (which constructs access by concatenating the code field from the sites table), the sys.userID field retrieved in the workflow incorrectly returns the session_id value from the end_user table.
The expected behavior is that sys.userID should return the primary key id field from the accounts table, which is a critical mismatch affecting user identity association and permission control.
Steps to reproduce:

  1. Deploy and run Dify 1.7.1
  2. Create a site and record the code field value in the sites table
  3. Access the workflow execution page via the URL constructed with the sites.code (the "Run" page)
  4. Add a custom code node/log node in the workflow to output the value of sys.userID
  5. Check the output: the value matches end_user.session_id instead of accounts.id

✔️ Expected Behavior

When accessing workflows through the "Run" page (using sites.code for access), the sys.userID field in the workflow should return the primary key id of the accounts table (the actual user ID).

❌ Actual Behavior

The sys.userID field returns the session_id value from the end_user table instead of the accounts.id primary key, leading to incorrect user identity mapping.

Originally created by @Zedthm on GitHub (Dec 10, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.7.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce Description: In Dify 1.7.1, when accessing workflows via the "Run" page (which constructs access by concatenating the code field from the sites table), the sys.userID field retrieved in the workflow incorrectly returns the session_id value from the end_user table. The expected behavior is that sys.userID should return the primary key id field from the accounts table, which is a critical mismatch affecting user identity association and permission control. Steps to reproduce: 1. Deploy and run Dify 1.7.1 2. Create a site and record the code field value in the sites table 3. Access the workflow execution page via the URL constructed with the sites.code (the "Run" page) 4. Add a custom code node/log node in the workflow to output the value of sys.userID 5. Check the output: the value matches end_user.session_id instead of accounts.id ### ✔️ Expected Behavior When accessing workflows through the "Run" page (using sites.code for access), the sys.userID field in the workflow should return the primary key id of the accounts table (the actual user ID). ### ❌ Actual Behavior The sys.userID field returns the session_id value from the end_user table instead of the accounts.id primary key, leading to incorrect user identity mapping.
yindo added the 🐞 bugoutdatedwont-fix labels 2026-02-21 20:09:55 -05:00
yindo closed this issue 2026-02-21 20:09:55 -05:00
yindo commented 2026-02-21 20:09:55 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 10, 2025):

This behavior is due to how Dify 1.7.1 handles user authentication and workflow execution for the "Run" page: when you access a workflow via a site URL, the system authenticates the user as an EndUser using a JWT, and the workflow context is built from the EndUser object. As a result, sys.userID is set to end_user.session_id, not accounts.id. This is confirmed in the workflow execution code, where sys.userID is assigned user.id if the user is an Account, but user.session_id if the user is an EndUser—external API calls (including the "Run" page) always use the EndUser path, so you get the session_id instead of the account ID (source, source).

There is no configuration in 1.7.1 to change this behavior; sys.userID will always reflect the session_id in this context (source). Some issues suggest manually using the correct accounts.id in API calls as a workaround, but this does not fix the workflow context for the "Run" page (source). Newer versions have improved user resolution logic, but in 1.7.1, the "Run" page is limited to session_id-based identification.

If you need sys.userID to match accounts.id for permission or mapping purposes, you may need to adapt your workflow logic or monitor for upstream fixes in future releases.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Dec 10, 2025): <!-- Answer --> This behavior is due to how Dify 1.7.1 handles user authentication and workflow execution for the "Run" page: when you access a workflow via a site URL, the system authenticates the user as an EndUser using a JWT, and the workflow context is built from the EndUser object. As a result, sys.userID is set to end_user.session_id, not accounts.id. This is confirmed in the workflow execution code, where sys.userID is assigned user.id if the user is an Account, but user.session_id if the user is an EndUser—external API calls (including the "Run" page) always use the EndUser path, so you get the session_id instead of the account ID ([source](https://github.com/langgenius/dify/blob/acdbcdb6f82b2ed2d48d5dd20cbfd745375588a6/api/core/app/apps/workflow/app_generator.py#L58-L502), [source](https://github.com/langgenius/dify/blob/acdbcdb6f82b2ed2d48d5dd20cbfd745375588a6/api/controllers/web/wraps.py#L27-L85)). There is no configuration in 1.7.1 to change this behavior; sys.userID will always reflect the session_id in this context ([source](https://github.com/langgenius/dify/issues/23396)). Some issues suggest manually using the correct accounts.id in API calls as a workaround, but this does not fix the workflow context for the "Run" page ([source](https://github.com/langgenius/dify/issues/15916)). Newer versions have improved user resolution logic, but in 1.7.1, the "Run" page is limited to session_id-based identification. If you need sys.userID to match accounts.id for permission or mapping purposes, you may need to adapt your workflow logic or monitor for upstream fixes in future releases. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/061b0621-5c26-4b89-9472-baf181976944?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/061b0621-5c26-4b89-9472-baf181976944?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/061b0621-5c26-4b89-9472-baf181976944?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/061b0621-5c26-4b89-9472-baf181976944?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/061b0621-5c26-4b89-9472-baf181976944?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/061b0621-5c26-4b89-9472-baf181976944?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/061b0621-5c26-4b89-9472-baf181976944?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=This%20behavior%20is%20due%20to%20how%20Dify%201.7.1%20handles%20user%20authentication%20and%20workflow%20execution%20for%20the%20%22Run%22%20page%3A%20when%20you%20access%20a%20workflow%20via%20a%20site%20URL%2C%20the%20system%20authenticates%20the%20user%20as%20an%20EndUser%20using%20a%20JWT%2C%20and%20the%20workflow%20context%20is%20built%20from%20the%20EndUser%20object.%20As%20a%20result%2C%20sys.userID%20is%20set%20to%20end_user.session_id%2C%20not%20accounts.id.%20This%20is%20confirmed%20in%20the%20workflow%20execution%20code%2C%20where%20sys.userID%20is%20assigned%20user.id%20if%20the%20user%20is%20an%20Account%2C%20but%20user.session_id%20if%20the%20user%20is%20an%20EndUser%E2%80%94external%20API%20calls%20%28including%20the%20%22Run%22%20page%29%20always%20use%20the%20EndUser%20path%2C%20so%20you%20get%20the%20session_id%20instead%20of%20the%20account%20ID%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/blob/acdbcdb6f82b2ed2d48d5dd20cbfd745375588a6/api/core/app/apps/workflow/app_generator.py%23L58-L502%29%2C%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/blob/acdbcdb6f82b2ed2d48d5dd20cbfd745375588a6/api/controllers/web/wraps.py%23L27-L85%29%29.%0A%0AThere%20is%20no%20configuration%20in%201.7.1%20to%20change%20this%20behavior%3B%20sys.userID%20will%20always%20reflect%20the%20session_id%20in%20this%20context%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/23396%29%29.%20Some%20issues%20suggest%20manually%20using%20the%20correct%20accounts.id%20in%20API%20calls%20as%20a%20workaround%2C%20but%20this%20does%20not%20fix%20the%20workflow%20context%20for%20the%20%22Run%22%20page%20%28%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/15916%29%29.%20Newer%20versions%20have%20improved%20user%20resolution%20logic%2C%20but%20in%201.7.1%2C%20the%20%22Run%22%20page%20is%20limited%20to%20session_id-based%20identification.%0A%0AIf%20you%20need%20sys.userID%20to%20match%20accounts.id%20for%20permission%20or%20mapping%20purposes%2C%20you%20may%20need%20to%20adapt%20your%20workflow%20logic%20or%20monitor%20for%20upstream%20fixes%20in%20future%20releases.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/29448)
yindo commented 2026-02-21 20:09:55 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Dec 10, 2025):

I think you should upgrade to the latest version, we do not have a plan to fix this in v1.7.1

@crazywoola commented on GitHub (Dec 10, 2025): I think you should upgrade to the latest version, we do not have a plan to fix this in v1.7.1
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label outdated wont-fix 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#20948
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?