Conversation
…modified Kudos Services to work based on permissions, instead of Admin.
…at for the kudos services to check for administer permissions (instead of using the admin role).
… permissions from admin, and fixed issues with user edit/delete.
| throw new PermissionException(NOT_AUTHORIZED_MSG); | ||
| } | ||
|
|
||
| UUID kudosId = kudos.getId(); |
There was a problem hiding this comment.
Do we not need to replace this with a permission check? I don't see it happening elsewhere in here, but I could be missing it.
There was a problem hiding this comment.
The controller handles this:
@Put
@RequiredPermission(Permission.CAN_ADMINISTER_KUDOS)
public Kudos approve(@Body @Valid Kudos kudos) {
return kudosServices.approve(kudos);
}
| throw new PermissionException(NOT_AUTHORIZED_MSG); | ||
| } | ||
|
|
||
| Kudos kudos = kudosRepository.findById(id).orElseThrow(() -> |
There was a problem hiding this comment.
Same above here. Is there a permission check happening?
There was a problem hiding this comment.
Same with the delete:
@Delete("/{id}")
@Status(HttpStatus.NO_CONTENT)
@RequiredPermission(Permission.CAN_ADMINISTER_KUDOS)
public void delete(@NotNull UUID id) {
kudosServices.delete(id);
}
|
|
||
| MemberProfile currentUser = currentUserServices.getCurrentUser(); | ||
| boolean isAdmin = currentUserServices.isAdmin(); | ||
| if (!isAdmin && (currentUser == null || !currentUser.getId().equals(memberProfile.getId()))) { |
There was a problem hiding this comment.
Was this an intentional or accidental can kicking? 🤣
There was a problem hiding this comment.
Well, intentional in that there are no required permissions to update a member profile. Since every member can update their own profile, I didn't see a way to limit which profile could be updated except by using the existing mechanism of checking for admin. But, as I'm writing this, I'm thinking that we could add a permission to be able to "update all profiles" and specifically check for it here instead of admin. Thoughts?
There was a problem hiding this comment.
Yes, I think that would work!
|
|
||
| @Override | ||
| @CacheInvalidate(cacheNames = {"member-cache"}) | ||
| public MemberProfile updateCurrentUserProfile(MemberProfile memberProfile) { |
There was a problem hiding this comment.
This seems to be misleading. This isn't related to the "current user" at all, is it? Am I missing something?
There was a problem hiding this comment.
Well, it is only called from the current user controller when updating the "last seen" for the current user.
There was a problem hiding this comment.
Maybe it should be renamed to something like "directProfileUpdate" or something indicating that there is no security related to it?
There was a problem hiding this comment.
Maybe we isolate that code to update the "last seen" here and call it something like 'updateLastSeen' and just pass in the user id? that feels less risky than an unsecured profile update API.
…lect its purpose.
…st seen field of a member profile to reduce the security impact.
2 participants
No description provided.