You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@rocketmq.apache.org by "tju-yxq (via GitHub)" <gi...@apache.org> on 2026/10/01 17:15:05 UTC
[I] [Studio][Feature] Suspected-credential-leak response requires revoking every session one user at a time [rocketmq-dashboard]
tju-yxq opened a new issue, #5306:
URL: https://github.com/apache/rocketmq-dashboard/issues/5306
## Problem
When a Studio credential leak is suspected — a shared workstation walked away, a token glimpsed in a screenshot, a browser profile copied — the incident response is to invalidate every live session so only fresh, verified logins keep working. Today that response has no lever: an administrator must open **each user's** session drawer on the User Management page and revoke that one account's sessions, user by user, while the page's own session overview counts exactly how many active sessions are sitting there outliving the incident.
The console clearly anticipates session hygiene — per-user revocation, the overview counters (active sessions, active users, expiring soon, stale) — but the one action an incident actually needs, "sign everyone out now", does not exist.
## Current behavior and reproduction
1. Sign in as an administrator and open **User Management**; the overview card reports, say, 12 active sessions across 8 users.
2. Decide all of them must be invalidated (suspected token leak).
3. Look for a global action on the overview card: there is none — the card is read-only statistics.
4. Open the first user's session drawer, click 注销全部, confirm. Repeat for the remaining 7 users. Interrupted halfway, the incident stays half-contained.
`server/src/main/java/org/apache/rocketmq/studio/auth/StudioUserController.java` (around lines 92-99) exposes revocation for exactly one account at a time:
```java
@PostMapping("/{userId}/sessions/revoke")
public Result<StudioUserSessionRevokeVO> revokeSessions(@PathVariable Long userId) {
int revokedSessionCount = authService.revokeSessionsForUser(userId);
...
}
```
And `AuthService.revokeUserSessions` (around line 553) always pins the statement to one account:
```java
private int revokeUserSessions(Long userId) {
LocalDateTime current = now();
return sessionMapper.update(null, new UpdateWrapper<RmqStudioSession>()
.eq("user_id", userId)
.isNull("revoked_at")
.gt("expires_at", current)
.set("revoked_at", current));
}
```
## Proposed behavior
- An administrator can revoke **every active session** from the User Management page in one confirmed action.
- The operator's **own** sessions are always spared: the responder who pulls the lever must not log themselves out mid-response, and can still revoke their own account from its drawer afterwards. The success message states this explicitly.
- A call without an authenticated principal (system-triggered) revokes everyone with no exclusion.
- The backend is one UPDATE over the same active-session predicate (`revoked_at IS NULL AND expires_at > now`) the per-user revoke uses, returning the affected row count.
- The overview card carries the action (destructive, behind a confirmation spelling out the effect), and after it runs the table, the overview counters and the session drawer all reflect the post-revocation state.
- The endpoint lives under `/api/studio-users/**`, which the `AuthInterceptor` already gates to administrators for non-GET methods; no other endpoint's behavior changes.
## Acceptance criteria
- [ ] `POST /api/studio-users/sessions/revoke-all` revokes every active session and returns the revoked count.
- [ ] The acting administrator's own sessions are excluded from the revocation.
- [ ] A request without an authenticated principal revokes every active session with no exclusion.
- [ ] Already-revoked and already-expired rows are untouched.
- [ ] The overview card offers the action behind a destructive confirmation; confirming reloads the user table and the overview counters and closes the open session drawer.
- [ ] The success message reports the revoked count and notes the operator's own sessions were kept.
- [ ] The per-user revoke action and all other endpoints behave exactly as before.
## Importance
Must-have. Session invalidation is the standard first move for a suspected credential leak on an operational console, and the current per-user loop makes the response slower than the incident. Workaround today: accept the per-user loop, or bounce the whole service (which also drops in-flight work for everyone and is rarely acceptable on a shared ops console).
## Duplicate check
Searched open and closed issues and PRs for `revoke all sessions` and `force logout`. The only adjacent item is #4060 (merged), which added the per-user session overview and revoke action this builds upon; nothing proposes a global revocation.
--
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: commits-unsubscribe@rocketmq.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Studio][Feature] Suspected-credential-leak response requires revoking every session one user at a time [rocketmq-dashboard]
Posted by "lizhimins (via GitHub)" <gi...@apache.org>.
lizhimins commented on issue #5306:
URL: https://github.com/apache/rocketmq-dashboard/issues/5306#issuecomment-6413039095
Resolved by #7311 (merged into rocketmq-studio as 5e6c8971e).
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Studio][Feature] Suspected-credential-leak response requires revoking every session one user at a time [rocketmq-dashboard]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on issue #5306:
URL: https://github.com/apache/rocketmq-dashboard/issues/5306#issuecomment-6071656441
This issue has been automatically closed because there has been no activity for 7 days. If you believe this issue is still relevant, please reopen it with updated information.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Studio][Feature] Suspected-credential-leak response requires revoking every session one user at a time [rocketmq-dashboard]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] closed issue #5306: [Studio][Feature] Suspected-credential-leak response requires revoking every session one user at a time
URL: https://github.com/apache/rocketmq-dashboard/issues/5306
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Studio][Feature] Suspected-credential-leak response requires revoking every session one user at a time [rocketmq-dashboard]
Posted by "lizhimins (via GitHub)" <gi...@apache.org>.
lizhimins closed issue #5306: [Studio][Feature] Suspected-credential-leak response requires revoking every session one user at a time
URL: https://github.com/apache/rocketmq-dashboard/issues/5306
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org