Copilot commented on code in PR #4798:
URL:
https://github.com/apache/rocketmq-dashboard/pull/4798#discussion_r4067250241
##########
server/src/main/java/org/apache/rocketmq/studio/auth/AuthController.java:
##########
@@ -60,12 +60,28 @@ public ResponseEntity<Result<AuthStatusVO>> status(
.body(Result.ok(status));
}
+ /**
+ * Reports the policy {@link AuthInterceptor} actually enforces, and
answers exactly as it does.
+ * Both read the same static property and the same runtime "requireLogin"
row, so the failure
+ * branches have to line up too: the frontend reads this flag to choose
between the login page
+ * and the console, and a policy that fails differently in the two places
strands the console.
+ * The interceptor fails closed (see its own {@code isLoginRequired}), so
an unreadable policy
+ * still demands a login here; letting the read failure escape as a 500
instead used to leave the
+ * frontend on its error screen, where the retry could never succeed and
the login page that
+ * would in fact work was unreachable.
Review Comment:
This fallback only keeps `/api/auth/status` at 200; `AuthService.login`
still calls `sessionTimeoutSeconds()` on both configured-user and
database-backed paths, and that method directly reloads `settingsRepository`.
With the same malformed JSON, a valid login still propagates
`BusinessException(500)`, so the login page is reachable but cannot actually
repair the settings as this comment claims. Make the session-timeout read fail
safe too, or narrow the recovery claim and scope of this change.
--
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]
