Re-inviting a removed member shows "workspace not found" error; invitation link logs in as admin account when opened in same browser

[maxleton-cyber]

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.15.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Bug 1 — Workspace not found:
1.Owner invites Member B via email
2.Member B accepts the invitation and joins the workspace
3.Owner removes Member B from the workspace via Members Management
4.Owner re-invites Member B using the same email address
5.Member B clicks the new invitation link
Bug 2 — Invitation link hijacked by admin session:
1.Admin is already logged in on Browser A
2.Admin sends an invitation link to Member B
3.Member B opens the invitation link in the same Browser A (where admin is already logged in)

✔️ Expected Behavior

1.Member B should be able to join the workspace successfully via the new invitation link.
2.The invitation link should either prompt Member B to log in with their own account, or show a warning that the current session belongs to a different user.

❌ Actual Behavior

(Bug 1)The invitation link shows the following error:
"workspace not found, please contact system admin to invite you to join in a workspace"
This only happens when re-inviting a previously removed member. First-time invitations work correctly. Checked tenant_account_joins table — no residual records found for the affected account. The account exists in the accounts table with status active.
(Bug 2)The browser automatically authenticates as the admin account instead of Member B. However, Member B appears as successfully joined in the members list, which is misleading and incorrect — the admin account was used to accept the invitation, not Member B's account.

[dosubot]

Hi @maxleton-cyber! I'm Dosu and I'm helping the Dify team.

I looked into both bugs you reported and can confirm these appear to be legitimate issues in the invitation flow logic. Here's what's happening:

Bug 1 — "Workspace not found" on re-invitation of a removed member:

When a member is removed, their TenantAccountJoin record is deleted [1]. However, the re-invitation logic in RegisterService.invite_new_member() handles three scenarios [2]:

1. No existing account → creates new account + membership
2. Existing account with PENDING status → allows re-invitation
3. Existing account with non-PENDING status → checks if TenantAccountJoin exists; if it does, raises AccountAlreadyInTenantError

For a previously removed active member (scenario 3), since their TenantAccountJoin was deleted, the invitation should succeed and a new token should be generated. The "workspace not found" error you're seeing likely occurs during the login flow after clicking the link [3] — if the re-invited member's account has no current workspace set (since their previous membership was deleted and the new one hasn't been activated yet), the login check fails with that message before they can even reach the activation step. The error message text matches the NotAllowedCreateWorkspace exception [4].

Bug 2 — Invitation link hijacked by admin session:

This is a design gap in the /activate endpoint [5]. The endpoint has no authentication decorators and doesn't validate the current browser session against the invitation recipient. When the activation is triggered:

• The database is updated to add the invitee's account to the workspace (using the account_id from the invitation token)
• But the browser's authentication cookies remain unchanged — the admin stays logged in
• The member list shows Member B as "joined" because the database was updated for their account, but the admin's session was never switched

This creates a session-database desynchronization where it appears Member B joined, but the activation was performed without proper identity verification.

Both issues would benefit from:

1. For Bug 1: Ensuring the re-invited member's account has a valid workspace context set during re-invitation, or that the activation link flow doesn't require a current workspace to proceed.
2. For Bug 2: Adding session validation to the /activate endpoint to either require logout first, prompt for the correct user's credentials, or warn that the current session belongs to a different user.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Taranum01]

I'd like to work on this. I'll open a PR shortly.

[Taranum01]

Stepping back from this one for now — it bundles two separate auth/session bugs and I want to make sure I can reproduce and test both paths locally before opening a PR. Happy for someone else to pick it up in the meantime.

[AsperforMias]

Stepping back from this one for now — it bundles two separate auth/session bugs and I want to make sure I can reproduce and test both paths locally before opening a PR. Happy for someone else to pick it up in the meantime.

hi, may i have a try for the remaining invite acceptance/session validation part of #38073 ?

I saw #38087 covers the re-invite membership path, so I’ll focus on preventing a logged-in different account from consuming another user’s invite token, while preserving accept-time workspace membership.