Frun1na opened a new issue, #6505:
URL: https://github.com/apache/rocketmq-dashboard/issues/6505

   ### Before Creating the Bug Report
   
   - [x] I have searched the [open 
issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository 
and believe that 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 current `rocketmq-studio` branch, or I 
have stated the exact version I am running below.
   
   ### Studio Version
   
   branch: `rocketmq-studio`
   git commit id: `779b8c0e`
   deployed as: reproduced by a unit test against that commit (the affected 
code is the backend service)
   
   ### Runtime Environment
   
   OS: Ubuntu on WSL2
   MySQL: not applicable — the defect is the missing audit write in 
`NameserverRegistryService`; the audit table is `rmq_operation_audit` from 
`db/schema.sql`
   browser: not applicable — reproduced in a JUnit 5 service test
   
   ### Connected RocketMQ Cluster
   
   RocketMQ version: not applicable — the write target is Studio's own registry 
row, not a broker call
   access mode: not applicable
   deployment: not applicable
   
   ### Describe the Bug
   
   The NameServer registry decides which endpoints the console is allowed to 
target
   (`NameserverRegistryService.requireRegisteredAddress` gates the nameserver 
and proxy entry points), and it is
   edited through three admin endpoints — `POST 
/api/nameservers/registry/create`, `/registry/update`,
   `/registry/delete`. None of them writes an operation-audit row:
   
   - `NameserverRegistryService.create` 
(`server/src/main/java/org/apache/rocketmq/studio/cluster/nameserver/NameserverRegistryService.java:52`,
     the insert at `:66` and the reload at `:71`), `update` (`:78`, write at 
`:96`, reload at `:105`) and
     `delete` (`:129`, `deleteById` at `:133`) call only the mapper; the 
service has no `OperationAuditService` dependency at all.
   - Every neighbouring operator-visible write does record one: ACL rules and 
users
     (`AclService.recordAudit`, including credential reveals, #5524), proxy 
addresses and proxy config reloads
     (`ProxyAddressService`, #5149), cloud credentials 
(`CloudCredentialService`), certificates
     (`K8sCertService`), cluster config 
(`ClusterService.recordConfigUpdateAudit`) and settings
     (`SettingsService`).
   
   The result is a blind spot in `/api/audit`: an operator can add, rename or 
remove the endpoint a cluster is
   reached through — including the k8s namespace and id the registry carries — 
and the audit log shows nothing,
   so the change cannot be attributed after the fact.
   
   ### Steps to Reproduce
   
   1. As an administrator, `POST /api/nameservers/registry/create` with 
`{"name":"prod","namesrvAddr":"prod-nameserver:9876"}`.
   2. `GET /api/audit` (or query `rmq_operation_audit`): no entry names `prod` 
or the `NAMESERVER_REGISTRY` resource.
   3. Without a running server and database, the same path is exercised from a 
unit test:
      `NameserverRegistryServiceTest.createShouldRecordARegistryAuditEntryTest` 
drives `service.create(...)` over a
      mocked `RmqNameserverMapper` and a mocked `OperationAuditService`.
   
   ### What Did You Expect to See?
   
   One audit row per accepted registry write, keyed like the neighbouring 
callers — operation
   `CREATE_NAMESERVER_REGISTRY` / `UPDATE_NAMESERVER_REGISTRY` / 
`DELETE_NAMESERVER_REGISTRY`, resource type
   `NAMESERVER_REGISTRY`, the entry name as the resource name (the deleted 
entry by id, with its name in the
   detail) and `SUCCESS`. A rejected write (duplicate name, malformed address, 
unknown id, concurrent delete)
   records nothing, the way `AclService` only audits completed operations.
   
   ### What Did You See Instead?
   
   `OperationAuditService` was never called: the assertion
   `verify(operationAuditService).record("CREATE_NAMESERVER_REGISTRY", 
"NAMESERVER_REGISTRY", "prod", null, "name=prod, 
namesrvAddr=prod-nameserver:9876", "SUCCESS", null)`
   fails with "Wanted but not invoked … Actually, there were zero interactions 
with this mock."
   
   ### Additional Context
   
   A fix with a regression test follows in a pull request.
   
   ### Are You Willing to Submit a Pull Request?
   
   - [x] Yes, I am willing to submit a pull request.
   


-- 
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]

Reply via email to