HLRest: refactor put_user to utilize User object#35188
Merged
albertzaharovits merged 5 commits intoelastic:masterfrom Nov 8, 2018
Merged
HLRest: refactor put_user to utilize User object#35188albertzaharovits merged 5 commits intoelastic:masterfrom
User object#35188albertzaharovits merged 5 commits intoelastic:masterfrom
Conversation
Collaborator
|
Pinging @elastic/es-core-infra |
albertzaharovits
commented
Nov 1, 2018
| builder.field("email", user.getEmail()); | ||
| } | ||
| builder.field("metadata", user.getMetadata()); | ||
| builder.field("enabled", enabled); |
Contributor
Author
There was a problem hiding this comment.
enabled has to be part of the request body entity, otherwise all users are put/updated as enabled.
albertzaharovits
commented
Nov 1, 2018
|
|
||
| private final String username; | ||
| private final Collection<String> roles; | ||
| private final Set<String> roles; |
Contributor
Author
There was a problem hiding this comment.
if User is both part of a response as well as a request, we have to acknowledge that roles can change order (through a round trip serialize-deserialize) but the User is still the same (from the equals POV).
albertzaharovits
commented
Nov 1, 2018
| "/_xpack/security/user/" + putUserRequest.getUser().getUsername()); | ||
| highLevelClient().getLowLevelClient().performRequest(deleteUserRequest); | ||
| } | ||
|
|
Contributor
Author
There was a problem hiding this comment.
Added IT for put_user .
jaymode
approved these changes
Nov 7, 2018
Member
jaymode
left a comment
There was a problem hiding this comment.
LGTM. Note, this is technically breaking-java since put user is in 6.5 the old way
Contributor
Author
|
True, thank you for pointing it out Jay, it did not realized it. |
albertzaharovits
added a commit
that referenced
this pull request
Nov 8, 2018
This follows #33552 , when the `_authenticate` API added a new `User` object for the API's response. This changes the `put_user` API to also employ a `User` object in the request. The User object changed slightly. A bug with put_user only putting/updating enabled (but not disabled) users has been fixed.
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
4 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.
This follows #33552 , when the
_authenticateAPI added a newUserobject for the API's response.This changes the
put_userAPI to also employ aUserobject in the request.The
Userobject changed slightly.A bug with
put_useronly putting/updating enabled (but not disabled) users has been fixed.CC @elastic/es-security