-
Notifications
You must be signed in to change notification settings - Fork 25k
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
[HLRC] Add support for get roles API #35787
Conversation
TODO: Implement GetRolesResponse once suppporting classes for roles are commited
Pinging @elastic/es-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.
LGTM, few comments once addressed, good to go. Thank you.
client/rest-high-level/src/main/java/org/elasticsearch/client/security/GetRolesResponse.java
Show resolved
Hide resolved
...high-level/src/test/java/org/elasticsearch/client/documentation/SecurityDocumentationIT.java
Outdated
Show resolved
Hide resolved
Thanks for the feedback @bizybot |
@@ -407,6 +409,35 @@ public DeleteRoleMappingResponse deleteRoleMapping(DeleteRoleMappingRequest requ | |||
DeleteRoleMappingResponse::fromXContent, emptySet()); | |||
} | |||
|
|||
/** | |||
* Retrieves roles in the native realm. |
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.
IMO s/native realm/native roles store/
(I know this comment uses the lingo from the docs)
builder.addPathPart(Strings.collectionToCommaDelimitedString(getRolesRequest.getRoleNames())); | ||
} | ||
return new Request(HttpGet.METHOD_NAME, builder.build()); | ||
|
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: extra line
import java.util.Set; | ||
|
||
/** | ||
* Request object to retrieve roles from the security index |
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.
IMO s/security index/native roles store
XContentParser.Token token; | ||
while ((token = parser.nextToken()) != XContentParser.Token.END_OBJECT) { | ||
XContentParserUtils.ensureExpectedToken(XContentParser.Token.FIELD_NAME, token, parser::getTokenLocation); | ||
roles.add(Role.PARSER.parse(parser, 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.
I think we lose the role name here. The Role
should have a name.
For this, the Role#fromXContent
could have a name parameter and be called here ; and not implement ToXContentObject
(PutRole
would build the XContent).
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 catch, I agree to have optional name parameter to Role#fromXContent
(the javadocs for the Role
will need an update)
@@ -79,6 +81,7 @@ | |||
PARSER.declareFieldArray(optionalConstructorArg(), ApplicationResourcePrivileges.PARSER, APPLICATIONS, ValueType.OBJECT_ARRAY); | |||
PARSER.declareStringArray(optionalConstructorArg(), RUN_AS); | |||
PARSER.declareObject(constructorArg(), (parser, c) -> parser.map(), METADATA); | |||
PARSER.declareObject(optionalConstructorArg(), (parser, c) -> parser.map(), TRANSIENT_METADATA); |
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.
Is there a difference between metadata
and transient_metadata
? If not I would make them both either optionalConstructorArg
(cautious) or constructorArg
(confident) :)
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 have recommended that the Role
have a name despite the idiosyncratic Response making it hard.
From the client perspective, it's cumbersome to manipulate a list of roles, from the response, in the order of the role names that have been requested. I would argue that returning a Collection
with Role
s having a name
as attribute follows closer the encapsulation precept.
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.
LGTM
Only fished the nits of the nits. These are totally optional.
Thanks for tackling this before put role! 🎩
...nt/rest-high-level/src/main/java/org/elasticsearch/client/security/user/privileges/Role.java
Outdated
Show resolved
Hide resolved
client/rest-high-level/src/main/java/org/elasticsearch/client/SecurityClient.java
Outdated
Show resolved
Hide resolved
...nt/rest-high-level/src/main/java/org/elasticsearch/client/security/user/privileges/Role.java
Show resolved
Hide resolved
@elasticmachine run the gradle build tests 1 |
@elasticmachine run the gradle build tests 1 |
This commits adds support for the Get Roles API to the HLRC Relates: #29827
This commits adds support for the Get Roles API to the HLRC
Relates: #29827