zmuxuny opened a new issue, #6024: URL: https://github.com/apache/rocketmq-dashboard/issues/6024
### Before Creating the Enhancement Request - [x] I have confirmed this is an enhancement rather than a bug or a new feature. - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) and believe this is not a duplicate. ### Summary ## Tracking continuation (2026-10-10) This replaces #5376, which was automatically closed by github-actions[bot] for inactivity on 2026-10-10. The issue's technical/design scope is preserved. Its current discussion and related issue/PR searches were rechecked before creating this continuation; no existing replacement issue was found. Existing implementation PR #5391 remains open and ready for review. This replacement restores issue tracking for that PR; no additional implementation PR is being proposed. The original report below retains its stated baseline and historical verification. It does not claim fresh test results, fully green CI, or new maintainer approval. Discussion and prior evidence remain available in #5376. Align first-run configuration and deployment examples with the login-required default established in #1673. Bootstrap should use operator-supplied credentials without temporarily disabling authentication. ### Motivation At rocketmq-studio 6a68042f, the copied environment example, standalone application configuration and remote setup instructions use different bootstrap assumptions. Operators can copy settings that do not match their intended login policy. Persisted users are authoritative; environment changes must never reset those accounts. ### Describe the Solution You'd Like - Keep login enabled in the general example, matching Compose and application defaults - Remove built-in standalone bootstrap credentials and copyable example passwords; require an explicit username/password for an empty user table, preserving existing fail-closed behavior when either is missing - Document that the login endpoint can seed the first configured account while authentication remains enabled - Correct English/Chinese quick-start, deployment and remote setup docs, including local HTTP cookie configuration and unchanged existing DB users - Add configuration-binding and bootstrap compatibility regressions This bounded change leaves runtime static-OR-persisted login policy, cookie defaults, network publication and existing accounts unchanged. ### Describe Alternatives You've Considered For a subsequent change, should unauthenticated development require a separate loopback-only Compose configuration, while general/remote deployment rejects disabled authentication? A backend behind a proxy cannot infer external reachability from its bind address. Changing existing publication or an explicit login override needs an agreed migration contract, so that broader mode split is separate from this bootstrap/template alignment. ### Additional Context Related: #1673 (merged, login-required/fail-closed direction), #2313 (merged, DB-authoritative users), #2161 (persistent-user design). #3374 and #2410 are closed/unmerged and cover different property-filtering/normalization cases. Searched open/closed issues and PRs for bootstrap/defaults, STUDIO_AUTH_LOGIN_REQUIRED, deployment authentication and loopback; no equivalent open change found. Focused regression preparation is underway; no deployed services or credentials are changed. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit 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]
