fix: enforce ownership when reading ChatUI sessions

[VectorPeak]

Fixes an ownership-boundary issue in ChatUI session reads: a dashboard user who knew another user's ChatUI session_id could request that session and reach message history scoped by the foreign session id.

Modifications / 改动点

What Problem This Solves

ChatService.get_session() is the shared service path behind both ChatUI session-read endpoints: the legacy query endpoint /api/chat/get_session?session_id={session_id} and the v1 REST endpoint /api/v1/chat/sessions/{session_id}. Before this change, the method accepted the caller-provided session_id, loaded the matching PlatformSession when one existed, and then continued without proving that the stored session owner matched the authenticated dashboard username. That left the read path different from nearby write/delete-style session operations, where session.creator is already treated as the owner boundary.

In that old flow, a logged-in dashboard user who knew another user's ChatUI session_id could reach the downstream lookup chain with a foreign session id. project_info was requested with the authenticated username, but message history was read from the platform history manager using the session's platform_id and user_id=session_id; in other words, the sensitive history lookup was keyed by the requested session id rather than by a prior creator check. This PR moves the existence and creator checks ahead of the project, history, and thread lookups, so those secondary reads only run after the session row is present and belongs to the requesting dashboard user.

The missing-session fallback weakened the same boundary. When db.get_platform_session_by_id(session_id) returned no PlatformSession, the previous code used platform_id = "webchat" and could still continue toward a history lookup for that raw session_id. This PR removes that fallback from the read path: a missing session now fails as Session ... not found, and an existing session with a different creator fails as Permission denied. The result is a narrow creator-ownership guard for these two ChatUI get-session endpoints, without claiming to change every session API surface.

Changes

• Reject missing sessions in ChatService.get_session() before looking up project info, message history, or threads.
• Reject sessions whose session.creator does not match the authenticated dashboard username.
• Keep the guard in the service-layer choke point shared by both get-session route wrappers.
• Leave sibling owner-checked flows unchanged, including session deletion, thread creation, message edit/regenerate, and display-name update paths.

Evidence

The regression test seeds a ChatUI session owned by another user, inserts message history under that foreign session_id, and verifies that the authenticated dashboard user receives status: error with Permission denied through both supported get-session routes:

GET /api/chat/get_session?session_id={session_id}
GET /api/v1/chat/sessions/{session_id}

Local validation is listed in Screenshots or Test Results / 运行截图或测试结果, including the targeted pytest run, the broader session-focused pytest run, Ruff lint, Ruff format check, and git diff --check.

Possible call chain / impact

Authenticated dashboard user
-> ChatUI get-session route
-> ChatService.get_session(username, session_id)
-> PlatformSession lookup by session_id
-> creator ownership check
-> project/history/thread lookup only after authorization passes

The affected sibling surfaces are the two get-session entry points listed above. This PR does not change session deletion, thread creation, message edit/regenerate, or display-name update flows; those paths already have owner checks. The intentional behavior change is that a nonexistent session now returns Session ... not found instead of falling back to webchat history lookup.

• This is NOT a breaking change. / 这不是一个破坏性变更。

Screenshots or Test Results / 运行截图或测试结果

No UI screenshots are included because this is a backend authorization boundary fix. Focused local validation:

uv run pytest tests/test_dashboard.py -k "get_chat_session_rejects_session_owned_by_another_user"
# 2 passed, 70 deselected, 1 warning

uv run pytest tests/test_dashboard.py -k "session"
# 6 passed, 66 deselected, 1 warning

uv run ruff check .
# All checks passed!

uv run ruff format --check .
# 479 files already formatted

git diff --check
# passed

The regression test creates a ChatUI session owned by not_dashboard_user, inserts message history under that foreign session_id, then verifies that an authenticated dashboard user receives status: error with Permission denied through both supported get-session routes.

---

Checklist / 检查清单

• 😊 If there are new features added in the PR, I have discussed it with the authors through issues/emails, etc.
  / 如果 PR 中有新加入的功能，已经通过 Issue / 邮件等方式和作者讨论过。

• 👀 My changes have been well-tested, and "Verification Steps" and "Screenshots" have been provided above.
  / 我的更改经过了良好的测试，并已在上方提供了“验证步骤”和“运行截图”。

• 🤖 I have ensured that no new dependencies are introduced, OR if new dependencies are introduced, they have been added to the appropriate locations in requirements.txt and pyproject.toml.
  / 我确保没有引入新依赖库，或者引入了新依赖库的同时将其添加到 requirements.txt 和 pyproject.toml 文件相应位置。

• 😈 My changes do not introduce malicious code.
  / 我的更改没有引入恶意代码。

Summary by Sourcery

Enforce ownership checks when retrieving ChatUI sessions from the dashboard to prevent unauthorized access to another user’s session data.

Bug Fixes:

• Reject reads of ChatUI sessions that are not owned by the requesting dashboard user.
• Return an explicit error when a requested ChatUI session does not exist instead of falling back to a default platform.

Tests:

• Add regression tests for both ChatUI get-session endpoints to ensure foreign-owned sessions are denied with a permission error.

[gemini-code-assist]

Code Review

This pull request introduces authorization checks to the get_session method in chat_service.py, raising an error if the session is not found or if the session creator does not match the requesting username. Additionally, a parameterized test has been added to verify that unauthorized requests to access another user's session are correctly rejected. I have no feedback to provide as there are no review comments.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[sourcery-ai]

Hey - I've left some high level feedback:

• Consider returning the same generic error message for both non-existent and unauthorized sessions (or avoiding the Session {id} not found detail) to prevent leaking information about session existence across ownership boundaries.
• In test_get_chat_session_rejects_session_owned_by_another_user, you might also assert that no project or message data is present in the response body to more explicitly verify that foreign-session data is not exposed even in error cases.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Consider returning the same generic error message for both non-existent and unauthorized sessions (or avoiding the `Session {id} not found` detail) to prevent leaking information about session existence across ownership boundaries.
- In `test_get_chat_session_rejects_session_owned_by_another_user`, you might also assert that no project or message data is present in the response body to more explicitly verify that foreign-session data is not exposed even in error cases.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}