btlqql opened a new issue, #4299:
URL: https://github.com/apache/rocketmq-dashboard/issues/4299
## 1. Symptom
`POST /api/k8s-certs/create` accepts certificate identities that `POST
/api/k8s-certs/update` refuses,
and stores them verbatim:
- a whitespace-only `issuer` (`" "`) or `k8sId`/`cluster` is accepted and
persisted without trimming,
while the same value sent to the update API is rejected with `400
Certificate issuer cannot be blank`;
- the stored value keeps its padding, so `k8sId` / `cluster` / `issuer` read
back as `" new-tls-cert "`.
The bundled web dialog happens to send `values.k8sId.trim()` and
`values.cluster.trim()`
(`web/src/pages/cluster/certs.tsx:104-105`), so the inconsistency only shows
for any other API client -
and the server is the component that owns the contract.
## 2. Root cause
`server/src/main/java/org/apache/rocketmq/studio/cluster/k8s/K8sCertService.java:81-95`
```java
String issuer = command.getIssuer();
List<String> san = command.getSan();
...
K8sCertVO cert = K8sCertVO.builder()
.k8sId(command.getK8sId())
.cluster(command.getCluster())
.type(type)
.issuer(issuer)
```
`createCert` passes the submitted identities straight through, while
`updateCert` routes the same three
fields through `normalizeOptionalIdentity` (`:120-122`, `:175-184`), which
trims and rejects a blank
value. `CreateCertDTO`'s `@NotBlank` constraints accept surrounding
whitespace, so they do not close the
gap either.
## 3. Impact
- A certificate row can be created in a state the update API cannot produce,
so the two write paths
disagree about what a valid identity is.
- Padded identities are stored and returned padded, which breaks later
exact-match lookups and makes the
inventory look like it contains duplicates (`"prod"` and `" prod"`).
- Fixing it afterwards requires an update call that a client written against
the create contract may not
expect to fail.
## 4. Reproduction
1. `POST /api/k8s-certs/create` with
`{"k8sId": " new-tls-cert ", "cluster": " test-cluster ", "type": "TLS",
"issuer": " vault "}`.
2. Response: 200 with `k8sId` `" new-tls-cert "` and `issuer` `" vault "`.
3. `POST /api/k8s-certs/update` with `{"id": <id>, "issuer": " "}`: `400
Certificate issuer cannot be
blank`.
## 5. Expected behaviour
- `createCert` normalises `k8sId`, `cluster` and `issuer` exactly like
`updateCert`: trimmed, blank
rejected with `400 Certificate <field> cannot be blank`.
- A value derived from a supplied `certPem` is unaffected: when a
certificate is uploaded, its parsed
issuer/SAN still win over the submitted ones.
--
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]
