Skip to content

Return a dependable, identifiable error when API Keys are not enabled #47759

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
cjcenizal opened this issue Oct 8, 2019 · 4 comments
Closed

Return a dependable, identifiable error when API Keys are not enabled #47759

cjcenizal opened this issue Oct 8, 2019 · 4 comments
Labels
:Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) Team:Deployment Management Meta label for Management Experience - Deployment Management team

Comments

@cjcenizal
Copy link
Contributor

If xpack.security.authc.api_key.enabled=false then the API keys API responds to requests with this error:

{
  status: 500,
  displayName: 'InternalServerError',
  message: '[illegal_state_exception] api keys are not enabled',
  body: {
    error: {
      root_cause: [
        Array
      ],
      type: 'illegal_state_exception',
      reason: 'api keys are not enabled'
    },
    status: 500
  },
  statusCode: 500
}

Currently, the UI needs to inspect the message string to determine whether the error is due to API keys being disabled or something else. This is brittle because there's no guarantee this message won't change.

This could be addressed by #35665.
@jimczi jimczi added the :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) label Oct 9, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security (:Security/Authentication)

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-ui (:ES-UI)

@tvernum
Copy link
Contributor

tvernum commented Feb 14, 2020

Discussed in #52311

@tvernum tvernum mentioned this issue Feb 26, 2020
Merged
tvernum added a commit that referenced this issue Mar 5, 2020
@tvernum
Add exception metadata for disabled features (#52811)
f5ba0f6 
This change adds a new exception with consistent metadata for when
security features are not enabled. This allows clients to be able to
tell that an API failed due to a configuration option, and respond
accordingly.

Relates: kibana#55255
Resolves: #52311, #47759
tvernum added a commit to tvernum/elasticsearch that referenced this issue Mar 23, 2020
@tvernum
Add exception metadata for disabled features
49979a0 
This change adds a new exception with consistent metadata for when
security features are not enabled. This allows clients to be able to
tell that an API failed due to a configuration option, and respond
accordingly.

Relates: kibana#55255
Resolves: elastic#52311, elastic#47759

Backport of: elastic#52811
@tvernum tvernum mentioned this issue Mar 23, 2020
Merged
tvernum added a commit that referenced this issue Mar 23, 2020
@tvernum
Add exception metadata for disabled features (#53941)
f003a41 
This change adds a new exception with consistent metadata for when
security features are not enabled. This allows clients to be able to
tell that an API failed due to a configuration option, and respond
accordingly.

Relates: kibana#55255
Resolves: #52311, #47759

Backport of: #52811
@tvernum
Copy link
Contributor

tvernum commented Mar 27, 2020

Resolved by #52811

@tvernum tvernum closed this as completed Mar 27, 2020
@codebrain codebrain mentioned this issue Apr 1, 2020
Closed
@cjcenizal cjcenizal added the Team:Deployment Management Meta label for Management Experience - Deployment Management team label Jun 9, 2020
@tvernum tvernum mentioned this issue Sep 21, 2021
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
:Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) Team:Deployment Management Meta label for Management Experience - Deployment Management team
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@cjcenizal @tvernum @elasticmachine @jimczi