ai-yang opened a new issue, #753:
URL: https://github.com/apache/rocketmq-dashboard/issues/753
## Problem
The `/studio/ssl-settings` page reports that SSL configuration was saved
successfully, but the configuration is neither sent to the server nor applied
anywhere.
## Reproduction
1. Open `/studio/ssl-settings`.
2. Enable SSL/TLS and enter a KeyStore path and password.
3. Optionally select a supported certificate or KeyStore file.
4. Click **Save**.
5. Observe the success notification.
6. Reload the page or navigate away and return.
The page returns to its hard-coded defaults. No save or upload request is
sent.
## Evidence
At `rocketmq-studio` commit `bbf1b7e0cf25a5065ba049b5450cc8155569f710`:
- `handleSave` only waits one second, displays `ssl.saveSuccess`, and
updates component-local React state.
- The page imports no API or service and never loads persisted SSL
configuration.
- `beforeUpload` returns `false` for every accepted file and there is no
`action` or `customRequest`, so valid files are never uploaded.
- Certificate metadata is hard-coded as:
- issuer: `Let's Encrypt`
- expiry: `2025-12-31`
- As of 2026-08-01, that expiry date is already 213 days in the past, but
the page still renders it with a green `Active` status.
The only related backend endpoint is `/api/ops/updateUseTLS`. It accepts
only a boolean, is used by the separate Ops page, and stores that value in an
in-memory field. There is no backend contract for loading, validating,
persisting, uploading, or applying the KeyStore/TrustStore configuration shown
by this page.
The K8s certificate endpoints are a separate metadata feature and do not
accept certificate contents or the SSL settings represented here.
## Deterministic regression
A real-page Node 20 regression enables TLS, enters a KeyStore path/password,
clicks **Save**, and advances the existing one-second timer with a fake clock.
Its guard assertion confirms that the current implementation publishes the
success notification and retains the fields for the current mount. The test
then unmounts and reopens the page.
On the latest unmodified `rocketmq-studio` baseline, 5/5 isolated Vitest
processes failed identically after reopen:
- the saved TLS switch was unchecked; and
- the submitted KeyStore path was empty.
The current-mount success/retention guard passed in every process. The test
uses no sleep, network, random scheduling, or external service.
## Impact
Administrators can be told that TLS was configured even though:
- the selected certificate or KeyStore was never uploaded;
- paths, passwords, protocol, and client-auth settings were never persisted;
- no runtime RocketMQ connection or server configuration was changed;
- an expired, synthetic certificate is displayed as active.
This can lead users to believe that a deployment is protected by TLS when it
is not.
## Expected behavior
The page should only report success after the server has validated and
accepted the configuration.
The intended design should define:
- whether settings apply globally, per RocketMQ cluster, or to Studio's own
server;
- how configuration is persisted and reloaded;
- how KeyStore/TrustStore files and passwords are handled securely;
- how the configuration is applied to runtime clients or services;
- how certificate metadata and expiry status are obtained from the actual
certificate.
If backend support is not intended yet, the page should be disabled or
clearly identified as unsupported instead of reporting a successful save.
## Related work
- #477 introduced the SSL settings page.
- #620 and #675 fixed UI state behavior but did not add persistence or
application logic.
- #704 concerns synthetic records in the separate K8s certificate
repository; this issue concerns the local-only save/upload behavior of
`/studio/ssl-settings`.
Immediate pre-publication searches across open and closed issues and open,
closed, and merged pull requests found no equivalent report, claimed
implementation, or assignee.
--
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]
