Wang1rrr opened a new issue, #4780:
URL: https://github.com/apache/rocketmq-dashboard/issues/4780
### Before Creating the Bug Report
- [x] Searched open and closed issues/PRs and checked related diffs.
- [x] This concerns RocketMQ Studio.
- [x] The exact inspected version and runtime scope are stated below.
### Studio Version
`rocketmq-studio` at `4c697f07acde460e2344375cb1f82669f5b270fd`.
### Runtime Environment
Windows, Node.js 22.23.2, the repository's existing Vitest/jsdom test
environment
and locked frontend dependencies. The real AclPage and Ant Design controls
were
rendered; the existing service mocks supplied synthetic Tencent roles.
### Connected RocketMQ Cluster
None. No cloud credentials, live Tencent API, Java/provider invocation or
Broker
were used. Observed behavior is at the frontend service-call boundary; the
provider target described below is established by source tracing, not a cloud
mutation test.
### Describe the Bug
Editing a Tencent ACL rule allows its principal to be changed to another
existing
role, while retaining the original row ID and original permissions. The
submitted
object can therefore have `id=reader-role` but `principal=publisher-role`.
Tencent roles have no database rule ID: the page uses principal as the row
ID,
while the provider updates a role by principal. The UI's editable field
changes
the update target rather than renaming the selected rule. With A=SUB and
B=PUB,
editing A, selecting B and keeping SUB constructs an update that targets B
with
A's permissions. This is an editing-object identity mismatch, not a claim of
an
authorization bypass.
### Steps to Reproduce
A safe component reproduction uses the existing AclPage test setup:
1. Select a `vendor: TENCENT` instance with ID `tencent-rmq`.
2. Return two rules with no numeric ID, Cluster resource `*`, ALLOW, and
cluster
scope: `reader-role` with actions `["SUB"]`, `publisher-role` with
`["PUB"]`.
Return the same two names from the user/role list.
3. Click **Edit** on reader-role's row. SUB is selected and PUB is not.
4. Use the real principal Select to choose publisher-role. The actions
remain SUB.
5. Click **Save** and capture the call to `aclService.updateAclRule`.
The actual captured request contains:
```json
{
"id": "reader-role",
"principal": "publisher-role",
"actions": ["SUB"],
"instanceId": "tencent-rmq"
}
```
A control using the same fixture without changing the principal submits
`id=reader-role, principal=reader-role`.
### What Did You Expect to See?
Editing an existing Tencent role's permissions should preserve that role's
identity. Choosing a role when creating a rule should remain possible;
editing
local Studio metadata should keep its current semantics.
### What Did You See Instead?
The principal selector permits A -> B, and Save sends an object with
inconsistent
row identity and update target while preserving A's selected permissions.
The existing 23 page tests pass. Two additional real-control diagnostics
produce
one passing unchanged-principal control and one failing identity-invariant
assertion after the actual A -> B request is captured. No production code was
changed for this observation. Earlier selector setup failures are not counted
as product evidence.
### Additional Context
Source chain at the version above:
- `web/src/pages/instance/acl.tsx`: normalizeRule falls back to principal
for ID;
edit-save spreads editingRule then form values; the Tencent principal
Select
remains editable.
- `web/src/services/aclService.ts`: forwards the edited rule to the update
API.
- `UpdateAclRuleDTO` intentionally accepts Tencent string identifiers by
converting
a nonnumeric ID to null; existing controller tests document this
compatibility.
- `AclService` dispatches the Tencent branch before local numeric-ID
handling.
- `TencentAclService.updateRule` delegates to createRule, which sends
ModifyRole
using principal as Role and sets both read/write permissions. In the
example,
the constructed target is publisher-role with read=true and write=false.
Do not change the intentional string-ID DTO compatibility to fix the UI.
A narrow proposed direction is to lock principal only while editing an
existing
Tencent rule, with regressions for unchanged edit identity, creation, and
local
metadata editing. No role migration, backend API or dependency change is
needed.
Related #4690 and #4574 concern AI projection/schema identifiers; #4670
concerns
query-string trimming. Their diffs do not change this editor path.
Prepared with AI assistance. The observation uses actual component
interactions
and synthetic service responses, not live cloud modification.
### Are You Willing to Submit a Pull Request?
- [x] Yes, after this issue, with focused regression tests and independent
review.
--
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]
