unbridled-41 opened a new issue, #4904:
URL: https://github.com/apache/rocketmq-dashboard/issues/4904
### Before Creating the Bug Report
- [x] I searched the open **and closed** issues of this repository and
believe this is not a duplicate.
- [x] This is a defect in RocketMQ Studio, not a usage question and not a
defect in another Apache RocketMQ repository.
- [x] I can reproduce this on the `rocketmq-studio` trunk (the branch this
repository's CONTRIBUTING.md points at); the exact commit is stated below.
### Studio Version
```
branch: rocketmq-studio (reproduced on
1ef5d860799ac3fabfcdea942cc4dcc77ded7be6, the base of the fixing PR)
deployed as: built from source
```
### Runtime Environment
```
OS: Ubuntu 22.04 (WSL2)
MySQL: not required — the defect is in a pure frontend function and is
reproduced by a unit test
browser (for UI issues): not required
```
### Connected RocketMQ Cluster
```
RocketMQ version: not required
access mode: not required
deployment: not required — the analysed input is what the server stores and
returns for an ACL
user; no broker or nameserver call is involved
```
### Describe the Bug
`analyzeAclRisk` (`web/src/utils/aclRiskDiagnostics.ts`) cannot read the
permission values the
server itself writes for a rule with more than one action, so a valid ACL
configuration is reported
as malformed and a genuinely risky default permission is not reported at all.
The rule editor lets one rule carry several actions (a `Checkbox.Group` with
PUB, SUB and ALL in
`web/src/pages/instance/acl.tsx`, the `actions` field). The repository
stores those actions as one
comma-joined value and hands it back verbatim:
```java
//
server/src/main/java/org/apache/rocketmq/studio/instance/acl/MybatisPlusAclRepository.java
String actions = joinNormalizedCsv(rule.getActions()); // "PUB,SUB"
...
topicPerms.add(rule.getResource() + "=" + actions); // ->
"order-events=PUB,SUB"
```
`examineBrokerClusterAclConfig` (same class) is what `GET
/api/acl/cluster-config` returns and what
`web/src/pages/instance/acl.tsx` feeds into `analyzeAclRisk`. Before the fix,
`normalizePermission` accepted only a single exact `DENY`/`PUB`/`SUB`/`ALL`
token and returned
`UNKNOWN` for anything else, with three consequences:
1. A valid entry such as `order-events=PUB,SUB` is reported as
`INVALID_PERMISSION_ENTRY` —
"权限条目格式无法识别" — on a page whose purpose is to flag real risks.
2. `defaultTopicPerm`/`defaultGroupPerm` of `PUB,SUB` ranks 0 in
`PERMISSION_ALLOW_RANK`, so
`hasDefaultAllow` is false: the account is missing from
`defaultAllowAccountCount` and neither
`DEFAULT_TOPIC_ALLOW` nor `DEFAULT_GROUP_ALLOW` is raised.
3. A `*=PUB,SUB` wildcard is scored as `warning` instead of `critical`,
although PUB+SUB is full
access — the same access as `*=ALL`, which the same function scores
`critical`.
### Evidence / Source
Unit tests added with the fix reproduce all three symptoms on the unfixed
code:
```
$ cd web && npx vitest run src/utils/aclRiskDiagnostics.test.ts
FAIL ... > reads the comma-joined action list the server writes for a
multi-action rule
AssertionError: expected [ 'INVALID_PERMISSION_ENTRY', …(1) ] to not include
'INVALID_PERMISSION_ENTRY'
FAIL ... > counts a comma-joined default permission as an allow
AssertionError: expected +0 to be 1 // Object.is equality
FAIL ... > ranks a publish+subscribe wildcard as full access
AssertionError: expected [ { …(8) }, { …(8) } ] to deeply equal
ArrayContaining{…}
Tests 3 failed | 4 passed (7)
```
The existing test suite only ever used single-action values, which is why
the mismatch was not
caught. Duplicate search: the only ACL-diagnostics issues are #4042
(regression coverage for
enabled clusters without accounts) and #3010 (the merged feature that
introduced the diagnostics);
neither covers multi-action values, and no open PR touches
`aclRiskDiagnostics.ts`.
### Impact
The ACL risk panel of the ACL page: a correctly configured account is shown
as having a malformed
permission entry, and an allow-by-default posture (`PUB,SUB`) is silently
absent from the risk
summary — a false negative on the page's core job. It affects any deployment
whose ACL rules carry
more than one action, in both UI languages, on every cluster.
### Expected Behaviour / Acceptance Criteria
- A permission value lists actions separated by commas (or
whitespace/semicolons) and is ranked by
its strongest action: `PUB,SUB` and `ALL` both mean full access.
- A multi-action entry is never reported as `INVALID_PERMISSION_ENTRY`.
- `defaultAllowAccountCount` counts an account whose default permission
contains any allowing action,
and `DEFAULT_TOPIC_ALLOW`/`DEFAULT_GROUP_ALLOW` are raised for it.
- A wildcard resource with `PUB,SUB` is `critical`, matching `*=ALL`.
- A value with no recognised action still reports `UNKNOWN`, and
single-action values keep their
current rank and severity.
### Corresponding Pull Request
- #4899 — `fix(acl): read the multi-action permission lists the server
writes`
### Additional Context
Found while auditing the ACL page against the values its own server writes;
the reproduction is the
unit test above (no cluster, no MySQL, no browser needed).
--
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]
