iloveeyjafjalla opened a new issue, #6860:
URL: https://github.com/apache/rocketmq-dashboard/issues/6860
## Summary
"Push ACL to broker" installs every stored account on the brokers **without
any of its policies**. The push reports success and shows `策略数 0` for each
account, but no `updateAcl` call is made, so the account ends up authenticated
but unauthorized on the broker.
## Why
The push looks each account's rules up under a principal no write path in
the product produces:
- `AclService.pushAclToBroker` reads them with
`aclRepository.findRulePage(principalOf(user.getUsername()), …)` —
`server/src/main/java/org/apache/rocketmq/studio/instance/acl/AclService.java:358-360`
— where `principalOf` returns `"user:" + username` (`:546-548`). The comment
beside `SUBJECT_PREFIX` states the wrong half of the assumption explicitly:
"the store uses `user:`" (`:62`).
- The store does not. `"user:"` occurs nowhere else in the main sources;
every write path stores the bare name: the console's rule form selects `value:
u.username` (`web/src/pages/instance/acl.tsx:1598-1601`), the plain-access
upsert stores the access key
(`MybatisPlusAclRepository.upsertPlainAccessRules`), and the AI tool stores
what the caller passes.
- `findRulePage` matches its principal filter as a **substring**
(`MybatisPlusAclRepository.ruleQuery` → `.like("principal", principal)`), so
`user:<name>` matches nothing for an account whose rules exist.
- With no rules, `upsertAccount` returns before `updateAcl`
(`AclService.java:459-461`) and the account's outcome is a success with
`policyCount=0`.
The `User:<name>` convention is real, but it belongs to the ACL 2.0 subject
the push *creates* on the broker, not to the key the Studio stores rules under.
## Impact
An account pushed this way can authenticate but not publish or subscribe:
the policies the operator created for it in the console never reach the broker.
The response, the per-account policy count, the audit row and the toast all
describe the push as successful, so the state is only visible if the operator
reads the policy count or checks the broker.
## Reproduction
`AclServiceTest.pushAclToBrokerPushesTheRulesStoredUnderTheAccountNameTest`
stores one account (`svc-a`), one rule whose principal is `svc-a`, and pushes:
```
expected: 1
but was: 0 (accounts[0].policyCount)
```
and `verify(admin).updateAcl(...)` fails because no policy is ever sent.
Live: ACL page on an Apache instance → create a user plus a rule for it → 推送
ACL 到 Broker → the toast reports success, the 策略数 column reads 0, and the
broker holds the account without policies.
## Expected
The push sends the rules the store holds for the account, so `policyCount`
matches what the console lists for that user and `updateAcl` runs with those
entries.
--
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]
