Request to redefine system variable user_id in difyChatbotConfig is invalid

[renandjie]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

I will embed the dify agent or chatflow into my own business system through JavaScript, but I hope that each user chat session can automatically record the login account and login ticket of my current business system, but I have not seen any docking parameters yet. I tried setting it up, but the user_id I saw on dify was still automatically generated by the system.

window.difyChatbotConfig = {
systemVariables: {
user_id: "eb747871-f4fb-4050-a15e-75e023a00041",
}
}

2. Additional context or comments

No response

[dosubot[bot]]

Hi @renandjie! I'm Dosu and I’m helping the dify team.

You can't directly override the internal user_id in difyChatbotConfig—Dify auto-generates and manages this value for session integrity and security. Attempts to set it manually are ignored or can cause errors, especially if the value doesn't match a valid session in the backend. This is by design, and recent backend changes have made this even stricter to prevent unauthorized session manipulation [source].

If you want to associate your business system's user identity (like login account or ticket) with Dify chat sessions, the recommended approach is to use reserved variables such as external_user_id for mapping your business users to Dify sessions. This allows you to track and link users without interfering with Dify's internal session management [source].

For iframe embedding, if you need to pass a user identifier, you must use the sys.user_id URL parameter, and it must be GZIP-compressed, Base64-encoded, and URI-encoded. For script embedding, you can set user-related variables in the config, but not the internal user_id [source].

If you try to set user_id to a value that doesn't match an existing session, Dify will either ignore it or treat the user as anonymous, which is why you see auto-generated IDs or errors [source].

To summarize: use external_user_id or similar reserved fields for your business mapping, and let Dify handle its own user_id. This is the supported and stable way to integrate user identity across systems.

To reply, just mention @dosu.

---

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

[renandjie]

My difyversion is 1.8.1; How to use the user variables defined by difyChatbotConfig in the prompt words of the agent or chatflow?
@dosu

[dosubot[bot]]

In Dify v1.8.1, you can reference user variables defined in window.difyChatbotConfig.userVariables (like external_user_id, name, avatar_url) directly in your agent or chatflow prompt templates using {{name}}, {{avatar_url}}, or {{external_user_id}}. You can also use the {{user.name}} style if you prefer—they both work for variables defined in userVariables.

Example config:

<script>
  window.difyChatbotConfig = {
    token: 'YOUR_CHATBOT_TOKEN',
    userVariables: {
      external_user_id: 'your-business-user-id',
      name: 'Alice Example',
      avatar_url: 'https://example.com/avatar.png'
    }
  }
</script>
<script src="https://YOUR_DIFY_HOST/embed.js"></script>

In your prompt or node, just use:
Welcome, {{name}} (ID: {{external_user_id}})!

Important: Only variables you explicitly define in userVariables will be available in prompts—except for sys.user_id, which is always present by default. If you want variables to be available for backend prompt processing (like in Orchestrate), you should also define them in the inputs section of difyChatbotConfig, for example:
window.difyChatbotConfig = { inputs: { name: 'Alice Example' } }
Otherwise, userVariables are mainly for frontend display (chat UI) and prompt injection, not for backend workflow logic [details & example].

Let me know if you need a more advanced example or have a specific workflow in mind!

To reply, just mention @dosu.

---

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

[renandjie]

Now I hope to pass the business system's tickets into an agent or chatflow embedded in JS, and make the users unaware. Which transmission method do you suggest? Mainly used for requesting MCP services in the future. @dosu

[dosubot[bot]]

For sensitive business tickets that should be invisible to users, avoid passing them via window.difyChatbotConfig fields (inputs, userVariables, systemVariables)—these are accessible in the browser and can be inspected by users or leaked in logs, so they're not secure for backend-only data transmission details.

The most secure method is to transmit tickets server-to-server or via secure HTTP headers, keeping them out of the frontend entirely details. If you must pass tickets from the frontend, use iframe embedding and encode the ticket as a URL parameter (gzip, base64, URI encode). This keeps the ticket out of inline JS and makes it less visible, but it's still not fully secure against browser inspection example & method:

import pako from 'pako';
function encodeParam(value) {
  const uint8Array = new TextEncoder().encode(value);
  const gzipped = pako.gzip(uint8Array);
  const base64Str = btoa(String.fromCharCode(...gzipped));
  return encodeURIComponent(base64Str);
}
const encodedTicket = encodeParam('YOUR_BUSINESS_TICKET');
const iframeUrl = `https://YOUR_DIFY_HOST/chat/{token}?ticket=${encodedTicket}`;

Then embed:

<iframe src={iframeUrl}></iframe>

Dify will decode and use this as an initial input for the session. But remember: anyone with browser access can still potentially see the ticket in the network tab or page source. For true backend-only security, handle tickets outside the frontend and inject them into Dify via API or server logic.

Let me know if you need a step-by-step for server-to-server integration or have a specific workflow in mind!

To reply, just mention @dosu.

---

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

[nicologiammaria]

@renandjie I am having the same issue you had, did you find a solution?
Adding "external_user_id" to the user variables doesn't work for me.
Also passing "user_id" in the system variables for some reason is saved in the Postgres table "end_users" under the column "session_id" instead of the column "external_user_id" or "user_id".
I am trying all suggestions found in issues, but I can't make it work properly.