X-LightYear opened a new issue, #5010:
URL: https://github.com/apache/rocketmq-dashboard/issues/5010
## Problem
The instance-scoped consumer-group detail endpoint does not verify that the
requested group belongs to the selected Studio instance before querying the
live RocketMQ endpoint.
## Current development branch
`master` / `rocketmq-studio` at `0228dad5b9c9460f3e18c5c3e2b56c6525856198`
(`chore(studio): 3.0.0 release readiness (#5007)`).
## Production path
`GET /api/groups/{name}?instanceId=...` →
`ConsumerGroupController.getConsumerGroup` → `MetadataService.getConsumerGroup`
→ the primary `RocketMQAdminClientImpl.getConsumerGroup`.
The metadata list path is instance-scoped through `InstanceProvider` and
`RocketMQMetadataProvider`, but the detail method calls the live admin client
directly without checking the persisted ownership row.
## Reproduction
1. Register two Apache Studio instances that point to the same RocketMQ
endpoint, for example `instance-a` and `instance-b`.
2. Register consumer group `buyers` under `instance-a` only.
3. Request `GET /api/groups/buyers?instanceId=instance-b`.
The current production path reaches the shared RocketMQ endpoint even though
the selected instance has no metadata ownership record for `buyers`.
The deterministic regression test is:
`MetadataServiceTest.consumerGroupDetailShouldRejectAGroupOutsideTheSelectedInstanceTest`
It models the production state by returning no `buyers` row from the
selected instance's metadata provider while the admin client can observe the
same live group.
## Expected behavior
The request should be rejected as not found for the selected instance,
without invoking the live admin client.
## Actual behavior
`MetadataService.getConsumerGroup` invokes
`AdminClient.getConsumerGroup(instanceId, name)` directly and returns the live
group, bypassing instance ownership.
## Root cause
The list and mutation paths enforce instance ownership, but the detail path
only validates the provider vendor and name. It does not require the group to
be present in the selected instance's persisted metadata scope.
## Duplicate analysis
Historical #1323/#1324 covered forwarding `instanceId` through the frontend
service contract. Historical #1338/#1359 covered forwarding row instance IDs
for subscription/progress diagnostics. This issue is different: the current
backend detail endpoint itself bypasses the selected instance's ownership scope
after receiving `instanceId`. No open Issue or PR was found for this exact
backend behavior.
## Scope
Only the instance-scoped consumer-group detail read path and deterministic
regression coverage.
No security claim is made; the impact is incorrect cross-instance data
visibility when instances share a RocketMQ endpoint.
--
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]
