Frun1na opened a new issue, #6507: URL: https://github.com/apache/rocketmq-dashboard/issues/6507
### 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 with stubbed credential repository and cloud clients in unit tests against that commit ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the cloud catalog entry points browser (for UI issues): not applicable ### Connected RocketMQ Cluster RocketMQ version: not applicable — reproduced with a stubbed `CloudCredentialRepository` and stubbed Tencent/Aliyun SDK clients access mode: not applicable deployment: Tencent Cloud TDMQ RocketMQ 5.x and ApsaraMQ for RocketMQ 5.x catalogs, exercised through factory stubs ### Describe the Bug The cloud catalog entry points accept a `credentialId` verbatim and never resolve it against the stored credentials: - `TencentCatalogService.listRegions` (`server/.../provider/tencent/TencentCatalogService.java:76-79`) only checks that the id is non-null and then returns the static `SUPPORTED_REGIONS` list, so `GET /api/cloud/tencent/regions?credentialId=<id>` is answered for a credential id that does not exist at all. - None of the six catalog entry points (`TencentCatalogService.listRegions` / `listCloudInstances` / `getCloudInstance`, `AliyunCatalogService.listRegions` / `listCloudInstances` / `getCloudInstance`) verifies the credential's vendor. A credential of the other vendor is handed to the vendor SDK, which only reports its own authentication failure, so the caller sees `422 Cloud credential is invalid` instead of "this credential belongs to Aliyun". - The sibling operation that consumes the same parameters already rejects both cases: `InstanceService.importCloudInstances` (`InstanceService.java:260-264`) throws `404 Cloud credential not found` and `400 Cloud credential vendor does not match TENCENT`/`ALIYUN` before it talks to the catalog. The create-instance wizard fetches regions with the credential id held in its form (`web/src/pages/instance/index.tsx:233-235`), so a credential deleted while the dialog is open — or any direct REST caller — gets a region picker the server cannot use, and the failure only appears on the following call. ### Steps to Reproduce The defect is pinned by unit tests; no live cloud account is needed: ``` cd server mvn -B -ntp test -DforkCount=1 -Dtest=TencentCatalogServiceTest,AliyunCatalogServiceTest ``` `TencentCatalogServiceTest.listRegionsShouldRejectAnUnknownCredentialTest` stubs `CloudCredentialRepository.findById(99L)` to return empty; `listRegionsShouldRejectACredentialOfTheOtherVendorTest` (both test classes) stubs the stored credential with the other vendor. Before the fix all six new cases fail with `Expecting code to raise a throwable.` because the call returns a region list instead of rejecting the request. ### What Did You Expect to See? A catalog request scoped to a credential the server cannot use should be rejected before any cloud call: `404 Cloud credential not found: <id>` for an unknown id, and `400 Cloud credential vendor does not match TENCENT`/`ALIYUN` for the other vendor's credential, with no interaction with the SDK client factory. This is what `InstanceService.importCloudInstances` already does for the same pair of arguments. ### What Did You See Instead? `GET /api/cloud/tencent/regions` returns 200 with all 19 Tencent regions for an unknown credential id, and every catalog call accepts the other vendor's credential id until the SDK answers `422 Cloud credential is invalid` — a message that points at the stored secret instead of the mismatch. ### Additional Context A fix with regression tests follows in 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]
