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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
