-
Notifications
You must be signed in to change notification settings - Fork 24.7k
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.
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
Add exception metadata for disabled features #52811
Merged
Merged
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
77bdebe
Add exception metadata for disabled features
tvernum 0c39f54
Revert format changes
tvernum d3caf0e
Fix imports
tvernum 25538dd
Add comments about string literals
tvernum 2597864
Merge branch 'master' into feature-not-enabled
tvernum File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
40 changes: 40 additions & 0 deletions
40
...ty/src/main/java/org/elasticsearch/xpack/security/support/FeatureNotEnabledException.java
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,40 @@ | ||
/* | ||
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one | ||
* or more contributor license agreements. Licensed under the Elastic License; | ||
* you may not use this file except in compliance with the Elastic License. | ||
*/ | ||
|
||
package org.elasticsearch.xpack.security.support; | ||
|
||
import org.elasticsearch.ElasticsearchException; | ||
import org.elasticsearch.rest.RestStatus; | ||
|
||
public class FeatureNotEnabledException extends ElasticsearchException { | ||
|
||
public static final String DISABLED_FEATURE_METADATA = "es.disabled.feature"; | ||
|
||
/** | ||
* The features names here are constants that form part of our API contract. | ||
* Callers (e.g. Kibana) may be dependent on these strings. Do not change them without consideration of BWC. | ||
*/ | ||
public enum Feature { | ||
TOKEN_SERVICE("security_tokens"), | ||
API_KEY_SERVICE("api_keys"); | ||
|
||
private final String featureName; | ||
|
||
Feature(String featureName) { | ||
this.featureName = featureName; | ||
} | ||
} | ||
|
||
public FeatureNotEnabledException(Feature feature, String message, Object... args) { | ||
super(message, args); | ||
addMetadata(DISABLED_FEATURE_METADATA, feature.featureName); | ||
} | ||
|
||
@Override | ||
public RestStatus status() { | ||
return RestStatus.BAD_REQUEST; | ||
} | ||
} |
This file contains 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
This file contains 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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder whether we should give
Feature
more attention to make it more formalized, because it seems to be an useful concept for other places as well. By formalization, I mean something like, have it in a separate class, place it in a shared package which is more accessible, name each feature more consistently (more on this below).Including Feature, we now have three different but related concepts: Feature, Setting, Plugin. Plugin seems to be the highest level, in that it provides one or multiple Features and Settings. I am not sure whether Feature has an 1-to-1 relationship with a
Setting
. If so, I feel the associated Setting should be reflected in this class and this could be useful for users to act accordingly.If the relationship between Feature and Setting is more complex, e.g. a feature corresponds to multiple Settings working together, it may need to be more carefully defined and promoted to be a first level concept. I am a bit surprised that Feature is not already an existing concept since both Setting and Plugin sound too technical when talking to users, while Feature seem to be a more accessible term.
I am aware that it is not something inherent to this PR so we don't need to solve it all with this PR. One possible actionable item is to move this class to a more common package for reuse by places other than security.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, no, maybe...
We do have "feature" concepts throughout the codebase. The obvious example being
isXyzzyAllowed()
on XPackLicenseState. Those are, roughly speaking, features.I can imagine a world when we had strong model of "Feature" and the license checks where all
isFeatureAllowed(Feature feature)
, and elsewhereisFeatureEnabled(Feature)
, but we don't and I don't think anyone wants to.The reason I added an enum here is
(String, String, Object ...)
and there would be ambiguity about whichString
was the feature name and which was the message.I think there's something to your suggestion, but progress over perfection - to me, this is a straight forward solution to the problem at hand, and we can evolve it into something else in the future if we need.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Enum is good (at least for now). I agree that we don't wanna stall on something that is not in scope of the problem at hand. My actual question is whether we should move this file to a more common module, e.g. the xpack
core
module for dependency sake, since I can see it being useful for other xpack modules besides security (similar to how license related files are incore
).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My personal view, is that it's a false sense of "reuse".
As it stands:
Based on the above, I understand the temptation to put it in core, but there's no clear value, and 1 definite limitation, so it seems like something that feels good for reuse purposes, but actually isn't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about using it in the "role template validation" if we chose to issue warning instead of error out. Since we have decided it's ok to error out, I currently have no other idea where it could be re-used. So the current form is ok with me.