-
Notifications
You must be signed in to change notification settings - Fork 275
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
Clean up REST API (Part 1) #2900
Clean up REST API (Part 1) #2900
Conversation
4eee5a7
to
cfb1543
Compare
Codecov Report
@@ Coverage Diff @@
## main #2900 +/- ##
============================================
+ Coverage 62.38% 62.44% +0.05%
+ Complexity 3379 3351 -28
============================================
Files 267 254 -13
Lines 19774 19735 -39
Branches 3355 3334 -21
============================================
- Hits 12336 12323 -13
+ Misses 5797 5779 -18
+ Partials 1641 1633 -8
|
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.
Hi @willyborankin looks pretty good. I left a couple nitpicky things but I also wanted to know what you felt was the best way to handle tests for the validator you added. Theoretically, it is always tested by everything that uses it, but perhaps we can add some explicit unit tests for the RequestContentValidator you added.
In theory, I think something could break and we would not have as straightforward of a time isolating the changes to the Validator as we could if you added some explicit tests on the class itself.
Let me know what you think.
src/main/java/org/opensearch/security/dlic/rest/api/AbstractApiAction.java
Show resolved
Hide resolved
src/main/java/org/opensearch/security/dlic/rest/api/AccountApiAction.java
Show resolved
Hide resolved
src/main/java/org/opensearch/security/dlic/rest/api/AuthTokenProcessorAction.java
Outdated
Show resolved
Hide resolved
src/main/java/org/opensearch/security/dlic/rest/api/PatchableResourceApiAction.java
Show resolved
Hide resolved
src/main/java/org/opensearch/security/dlic/rest/api/ValidateApiAction.java
Outdated
Show resolved
Hide resolved
src/main/java/org/opensearch/security/dlic/rest/validation/RequestContentValidator.java
Outdated
Show resolved
Hide resolved
061d2da
to
1441831
Compare
Agree I added a new |
845dabe
to
a1a46e2
Compare
@opensearch-project/security can we get another review here to move this PR forward? Thank you! |
@opensearch-project/security bumping this PR again for a second review. |
a1a46e2
to
80d3e61
Compare
src/main/java/org/opensearch/security/dlic/rest/api/AbstractApiAction.java
Show resolved
Hide resolved
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.
Thank you @willyborankin. This is cleaner than the existing implementation and I'm looking forward to see what Part II entails. I took a first pass and left a few comments.
switch (request.method()) { | ||
case DELETE: | ||
handleDelete(channel, request, client, validator.getContentAsNode()); | ||
handleDelete(channel, request, client, null); |
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.
Do handleDelete
and handleGet
use the JsonNode parameter anywhere?
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.
They are not, I intentionally left them as is, the next PR will change this logic
} | ||
|
||
@Override | ||
public Map<String, RequestContentValidator.DataType> allowedKeys() { |
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.
This is much cleaner than now. Ultimately, I'd like to see this defined with an OpenAPI spec like syntax one day
} | ||
allowedKeys.put("allowed_actions", DataType.ARRAY); | ||
allowedKeys.put("description", DataType.STRING); | ||
allowedKeys.put("type", DataType.STRING); |
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.
String is overly generic here. Is there an enum for type (i.e. INDEX, CLUSTER) somewhere?
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.
Good point! There are no enums or constants except MutitenecyActionApi. I can extract all of them as enums, and some of them have the same name in the next small PR.
if (isSuperAdmin()) { | ||
allowedKeys.put("reserved", DataType.BOOLEAN); | ||
} | ||
allowedKeys.put("allowed_actions", DataType.ARRAY); |
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.
Does this go beyond defining an array? i.e. an array of action names (strings) vs an array of booleans
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.
No it doesn't and same for DataType.OBJECT
. I noticed it as well.
} | ||
|
||
@Override | ||
public Set<String> mandatoryOrKeys() { |
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.
Nice! I like this vs writing this as an if statement checking if at least one is nonNull.
requestedKeys.removeAll(allowed); | ||
invalidKeys.addAll(requestedKeys); | ||
if (!missingMandatoryKeys.isEmpty() || !invalidKeys.isEmpty() || !missingMandatoryOrKeys.isEmpty()) { | ||
this.validationError = ValidationError.INVALID_CONFIGURATION; |
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.
nit: Is CONFIGURATION the right term to use here? wdyt INVALID_PAYLOAD
?
Would this message be able to be descriptive around what is invalid about the payload when responding to the caller? i.e. This request is missing required keys key1, key2, key3?
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.
nit: Is CONFIGURATION the right term to use here? wdyt
INVALID_PAYLOAD
?
INVALID_PAYLOAD
looks better agree originally it is INVALID_CONFIGURATION
.
Would this message be able to be descriptive around what is invalid about the payload when responding to the caller? i.e. This request is missing required keys key1, key2, key3?
yes the response looks something like:
{
"status": "error"
"reason": "",
"invalid_keys": {"keys":"a,b,c"},
"missing_mandatory_keys": {"keys": "d,e,f"},
"specify_one_of": {"keys": "g,h"}
}
d19308f
to
a816aac
Compare
Rebased with main |
@willyborankin Please add the backport 2.x label if you want this backported to 2.x for an upcoming release. |
@scrawfor99 Let's release it in 2.10; there's no rush. |
a816aac
to
1c45c0c
Compare
Removed redundant classes for the request content validation Signed-off-by: Andrey Pleskach <ples@aiven.io>
Request content validator code cleaning Signed-off-by: Andrey Pleskach <ples@aiven.io>
1c45c0c
to
a336e88
Compare
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.x 2.x
# Navigate to the new working tree
cd .worktrees/backport-2.x
# Create a new branch
git switch --create backport/backport-2900-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 6bac470df67b16a22f496b052776e7afdd50e900
# Push it to GitHub
git push --set-upstream origin backport/backport-2900-to-2.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.x Then, create a pull request where the |
The aim of this PR is to start cleaning code in REST API since with the current implementation is difficult to understand and support. Changes: - Implemented new `RequestConetnValidator` class which uses the same validation logic as `AbstractConfigurationValidator` - Removed all redundant `AbstractConfigurationValidator` extensions [Please provide details of testing done: unit testing, integration testing and manual testing] - [ ] New functionality includes testing - [ ] New functionality has been documented - [ ] Commits are signed per the DCO using --signoff By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. For more information on following Developer Certificate of Origin and signing off your commits, please check [here](https://github.com/opensearch-project/OpenSearch/blob/main/CONTRIBUTING.md#developer-certificate-of-origin). --------- Signed-off-by: Andrey Pleskach <ples@aiven.io> (cherry picked from commit 6bac470)
The aim of this PR is to start cleaning code in REST API since with the current implementation is difficult to understand and support. Changes: - Implemented new `RequestConetnValidator` class which uses the same validation logic as `AbstractConfigurationValidator` - Removed all redundant `AbstractConfigurationValidator` extensions [Please provide details of testing done: unit testing, integration testing and manual testing] - [ ] New functionality includes testing - [ ] New functionality has been documented - [ ] Commits are signed per the DCO using --signoff By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. For more information on following Developer Certificate of Origin and signing off your commits, please check [here](https://github.com/opensearch-project/OpenSearch/blob/main/CONTRIBUTING.md#developer-certificate-of-origin). --------- Signed-off-by: Andrey Pleskach <ples@aiven.io> (cherry picked from commit 6bac470)
The aim of this PR is to start cleaning code in REST API since with the current implementation is difficult to understand and support. Changes: - Implemented new `RequestConetnValidator` class which uses the same validation logic as `AbstractConfigurationValidator` - Removed all redundant `AbstractConfigurationValidator` extensions [Please provide details of testing done: unit testing, integration testing and manual testing] - [ ] New functionality includes testing - [ ] New functionality has been documented - [ ] Commits are signed per the DCO using --signoff By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. For more information on following Developer Certificate of Origin and signing off your commits, please check [here](https://github.com/opensearch-project/OpenSearch/blob/main/CONTRIBUTING.md#developer-certificate-of-origin). --------- Signed-off-by: Andrey Pleskach <ples@aiven.io> (cherry picked from commit 6bac470) Signed-off-by: Andrey Pleskach <ples@aiven.io>
### Description Reacting to changes from the backport of opensearch-project/OpenSearch#9262. This reason the main branch of Security is not encountering these errors is because the affected class was removed in #2900 and the change has not been backported yet. @willyborankin are you planning to backport #2900? * Category (Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation) Maintenance ### Check List - [ ] New functionality includes testing - [ ] New functionality has been documented - [ ] Commits are signed per the DCO using --signoff By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. For more information on following Developer Certificate of Origin and signing off your commits, please check [here](https://github.com/opensearch-project/OpenSearch/blob/main/CONTRIBUTING.md#developer-certificate-of-origin). Signed-off-by: Craig Perkins <cwperx@amazon.com>
The aim of this PR is to start cleaning code in REST API since with the current implementation is difficult to understand and support. Changes: - Implemented new `RequestConetnValidator` class which uses the same validation logic as `AbstractConfigurationValidator` - Removed all redundant `AbstractConfigurationValidator` extensions [Please provide details of testing done: unit testing, integration testing and manual testing] - [ ] New functionality includes testing - [ ] New functionality has been documented - [ ] Commits are signed per the DCO using --signoff By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. For more information on following Developer Certificate of Origin and signing off your commits, please check [here](https://github.com/opensearch-project/OpenSearch/blob/main/CONTRIBUTING.md#developer-certificate-of-origin). --------- Signed-off-by: Andrey Pleskach <ples@aiven.io> (cherry picked from commit 6bac470) Signed-off-by: Andrey Pleskach <ples@aiven.io>
The aim of this PR is to start cleaning code in REST API since with the current implementation is difficult to understand and support. Changes: - Implemented new `RequestConetnValidator` class which uses the same validation logic as `AbstractConfigurationValidator` - Removed all redundant `AbstractConfigurationValidator` extensions Signed-off-by: Andrey Pleskach <ples@aiven.io> (cherry picked from commit 6bac470) Signed-off-by: Andrey Pleskach <ples@aiven.io>
The aim of this PR is to start cleaning code in REST API since with the current implementation is difficult to understand and support. Changes: - Implemented new `RequestConetnValidator` class which uses the same validation logic as `AbstractConfigurationValidator` - Removed all redundant `AbstractConfigurationValidator` extensions Signed-off-by: Andrey Pleskach <ples@aiven.io> (cherry picked from commit 6bac470) Signed-off-by: Andrey Pleskach <ples@aiven.io> Signed-off-by: Andrey Pleskach <ples@aiven.io>
Description
The aim of this PR is to start cleaning code in REST API since with the current implementation is difficult to understand and support.
Changes:
RequestConetnValidator
class which uses the same validation logic asAbstractConfigurationValidator
AbstractConfigurationValidator
extensionsTesting
[Please provide details of testing done: unit testing, integration testing and manual testing]
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.