Copilot commented on code in PR #4220:
URL: https://github.com/apache/hertzbeat/pull/4220#discussion_r3623366220
##########
hertzbeat-alerter/src/main/java/org/apache/hertzbeat/alert/service/impl/NoticeConfigServiceImpl.java:
##########
@@ -176,9 +177,23 @@ public void addReceiver(NoticeReceiver noticeReceiver) {
@Override
public void editReceiver(NoticeReceiver noticeReceiver) {
+ resolveMaskedSecrets(noticeReceiver);
noticeReceiverDao.save(noticeReceiver);
}
+ /**
+ * The rest api returns receivers with masked secret fields, so a receiver
submitted
+ * from the ui may carry the mask placeholder instead of the real secret.
+ * Restore such fields from the stored entity before using the receiver.
+ */
+ private void resolveMaskedSecrets(NoticeReceiver noticeReceiver) {
+ if (noticeReceiver == null || noticeReceiver.getId() == null) {
+ return;
+ }
+ noticeReceiverDao.findById(noticeReceiver.getId())
+ .ifPresent(existing ->
NoticeReceiverMaskUtil.resolveMask(noticeReceiver, existing));
+ }
Review Comment:
`resolveMaskedSecrets` silently does nothing when `id` is provided but the
receiver cannot be loaded. With the new masked-credential round-trip, that can
result in persisting the UI placeholder (e.g., `******voJM`) or effectively
turning `PUT /receiver` into an unintended upsert. Consider failing fast when
an `id` is supplied but no stored receiver exists, so masked placeholders can
never be saved to the database.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
