If you don't want your JQL function to violate the strict security aspects of your JIRA instance, sanitizing the JQL functions is a must! So, what does this actually mean?
Imagine a filter created by you to find out issues in a pre-defined set of projects. What will happen if you share the filter with a friend of yours who is not supposed to see the project or know that the project existed? The person with whom you shared it won't be able to modify the issues in the protected project due to JIRA's permission schemes, but they will surely see the name of the project in the JQL query that is used in the filter.
This is where sanitizing the JQL function will help. In essence, we just modify the JQL query to protect the arguments in line with the permission schemes. Let us see an example of doing that by sanitizing the JQL function we created in the previous recipe.
In our JQL function, we use the project keys as the arguments. To explain the function sanitization, we will look to replace the keys with project IDs whenever the user doesn't have permission to browse a project. The following is the step-by-step process showing you how to do it:
ClauseSanitisingJqlFunction
interface:public class ProjectsFunction extends AbstractJqlFunction implements ClauseSanitisingJqlFunction{
sanitiseOperand
method. In this method, we read all the existing arguments of the JQL function, from the FunctionOperand
argument, and modify them to include project IDs instead of keys, wherever the user doesn't have Browse permissions:@Override public FunctionOperand sanitiseOperand(ApplicationUser user, FunctionOperand functionOperand) { final List<String> pKeys = functionOperand.getArgs(); boolean argChanged = false;final List<String> newArgs = new ArrayList<String>(pKeys.size()); for (final String pKey : pKeys) { Project project = projectManager.getProjectObjByKey(pKey); if (project != null && !permissionManager.hasPermission (ProjectPermissions.BROWSE_PROJECTS, project, user)) { newArgs.add(project.getId().toString()); argChanged = true; } else { newArgs.add(pKey); } } if (argChanged) { return new FunctionOperand(functionOperand.getName(), newArgs); } else { return functionOperand; } }
Once the plugin is deployed, if a user doesn't have the permission to browse a project, they will see the project ID instead of the key that was originally entered when the filter was created. The following is a sample screenshot of how the query will look in that case. In this case, I just removed myself from the Browse permission of the TEST
project, and you can see that the query is modified to replace the key TEST
with its unique ID, which doesn't reveal much information:
This is only an example, and we can sanitize even more complex queries to hide sensitive data from users without the required privileges.
18.216.143.65