fix(api): /_xpack reports real auth state instead of hardcoded true - #9
Merged
xerj-team merged 1 commit intoJul 24, 2026
Conversation
… hardcoded true Both xpack_info (GET /_xpack) and its usage endpoint hardcoded features.security.enabled = true regardless of how the server was actually started, including under --insecure. Kibana decides whether to show its login screen based on this flag, not on _security/_authenticate — so with --insecure (auth genuinely disabled) Kibana still always renders the login form, and the actual auth state and the state XERJ reports diverge. Fix: read state.config.auth.enabled instead, so the reported value matches reality. Verified: Kibana 8.13 skips the login screen entirely once this reflects false under --insecure.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GET /_xpackandGET /_xpack/usagehardcodefeatures.security.enabled = true, regardless of how the server was actually started — including under--insecure.Why this matters: Kibana decides whether to show its login screen based on this flag, not on
_security/_authenticate. So with--insecure(auth genuinely disabled), Kibana still always renders the login form — and worse, login itself then fails with a 500 on user-profile activation, since XERJ is telling Kibana security is on while behaving as if it's off.Fix: both endpoints now read
state.config.auth.enabledinstead of a hardcodedtrue.Verified: with this change and
--insecure, Kibana 8.13 skips the login screen entirely and lands directly on the app — confirmed against a local Kibana instance.