-
Story
-
Resolution: Done
-
Normal
-
None
-
None
-
5
-
False
-
-
False
-
Unset
-
None
-
-
Description
The handlers that use Kessel Relations were split as follows:
public Response originalHandler() { if (kesselRelationsEnabled()) { // Check Kessel permission. internalHandler(); } else { legacyRbacOriginalHandler(); } } @RollesAllowed(ConsoleIdentityProvider.RBAC_SOME_PERMISSION) public Response legacyRbacOriginalHandler() { internalHandler(); } public Response internalHandler() { // Do stuff and return a response. }
So, basically, the original handler has no authorization restriction, and just acts as a dispatcher depending on which authorization system is enabled. The problem is that that approach created lots of cluttered code which is hard to maintain and follow.
However, we revert all that back by using the securityContext.isUserInRole.(ConsoleIdentityProvider.RBAC_SOME_PERMISSION) utility instead.
Acceptance criteria
The handlers get merged back in a single function, without a @RolesAllowed annotation, and by following the structure below:
public Response originalHandler() { if (kesselRelationsEnabled()) { // Check Kessel permission. } else { if (!securityContext.isUserInRole(ConsoleIdentityProvider.RBAC_SOME_ROLE)) { throw new ForbiddenException(); } } // The "internal" function's code goes back here. }
That block of code might be suitable for some generalization to avoid repeating the same code block in every handler.
- mentioned on
