tju-yxq opened a new issue, #5313:
URL: https://github.com/apache/rocketmq-dashboard/issues/5313
## Problem
Every Studio session is anonymous. The user management drawer shows a
session's id, status, last-seen and expiry — but not **where it came from**.
When an administrator reviews a user's active sessions during an incident ("the
contractor left three weeks ago, why are there two active sessions?", "which of
these five is the one from the shared kiosk?"), there is nothing to distinguish
a session issued from the user's own browser from one issued by an unknown
client on another network. Session hygiene actions — revoke one, revoke all,
idle timeouts, global revocation — all exist, but the decision of *which*
session is suspicious has to be made blind.
Client attribution on issued sessions is the standard control for exactly
this: every mature console shows "signed in from 203.0.113.7 with Chrome on
macOS" next to each session.
## Current behavior and reproduction
1. Sign in from two different browsers (or one browser and a curl with the
bearer token).
2. As an administrator, open **User Management**, open that account's
session drawer.
3. The two sessions differ only by id and timestamps. There is no address,
no user agent — no way to tell them apart or to recognize either one later in
an audit.
Code facts:
`server/src/main/java/org/apache/rocketmq/studio/persistence/entity/RmqStudioSession.java`
carries only `userId`, `tokenHash`, `expiresAt`, `revokedAt`, `lastSeenAt` and
the timestamps — no client columns. The `rmq_studio_session` table in
`server/src/main/resources/db/schema.sql` (around lines 45-58) matches, and
`AuthController.login` (around line 78) passes only the credential DTO to the
service: the request's address and `User-Agent` are available right there and
discarded.
## Proposed behavior
- `rmq_studio_session` gains `client_ip` (VARCHAR 64) and `user_agent`
(VARCHAR 255).
- A startup migration adds both columns to databases created before the
current schema, following the existing `QueryHistorySchemaMigration` pattern:
metadata-checked, idempotent, tolerant of concurrent instances. Existing rows
keep NULL.
- The login controller forwards the client address and `User-Agent`. Behind
a reverse proxy the socket address is the proxy's, so the **first
X-Forwarded-For hop** is preferred when present. The values are observability
metadata only — never used for authorization — and long user agents are
truncated to the column width instead of failing the login.
- The session drawer gains an **Origin** column showing the address, with
the full user agent on hover; sessions created before attribution (NULL) render
a dash.
- The properties-based (in-memory) auth mode is unchanged: it is the
single-user dev fallback and records no session rows.
## Acceptance criteria
- [ ] A login from a direct connection records the socket address as
`client_ip`.
- [ ] A login behind a proxy with `X-Forwarded-For: 203.0.113.7, 10.0.0.1`
records `203.0.113.7`.
- [ ] The request's `User-Agent` is recorded, truncated to 255 characters
when longer.
- [ ] Logins through the API without a user agent keep the column NULL.
- [ ] The migration adds both columns to a pre-existing table, preserves its
rows, is idempotent, and skips when the table does not exist.
- [ ] The drawer shows the address with the user agent on hover, and a dash
for legacy rows.
- [ ] Authorization decisions remain entirely independent of the recorded
values.
## Importance
Must-have. Session review is the first step of every credential-incident
response, and today it is done blind; the workaround is correlating
reverse-proxy or application access logs by timestamp, which is slow, often
rotated away, and unavailable to operators without infrastructure access.
## Duplicate check
Searched open and closed issues and PRs for `session IP`, `user agent`, and
`client address`. The hits are unrelated (producer-group client composition
#3158, IPv6 ACL whitelist #2246, producer connection identity #2145); nothing
proposes session client attribution.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
