Restricting Groovy's Access

Restricting Groovy's Access

This section describes functionality that can be restricted by the software license for JasperReports Server. If you don’t see some of the options described in this section, your license may prohibit you from using them. To find out what you're licensed to use, or to upgrade your license, contact Jaspersoft.

JasperReports Server relies on Apache Groovy in a number of contexts, including:

When a Domain definition includes a security file that determines which users or roles have access to various data.
When a calculated field in an Ad Hoc view or Domain relies on a Groovy expression.

By default, Groovy is given broad access within your application server, which is a good approach to certain design, testing, and evaluation tasks. However, some production systems should be configured to restrict Groovy to more limited access by creating a whitelist that only includes the classes Groovy should access. Once configured, the server returns an error when the Groovy compiler encounters code that doesn't conform to the whitelist.

Groovy's access is set at the server level; configure it by editing properties files as well as a Groovy source file:

1. Configure the groovyRunner to enable the restriction in general.
2. Configure the preprocessor to enable the restriction for Groovy expressions in DomEL.
3. Optionally configure the whitelist to allow Groovy access to additional classes.

First, enable the Groovy restriction:

Groovy Restriction

Configuration File







Uncomment this property to enable the restriction.

In addition to enabling the Groovy restriction, configure the DomEL preprocessor:

DomEL Restriction

Configuration File







Set this value to true to apply the Groovy restriction to all DomEL expressions that rely on the groovy() function.

Optionally, you can extend the whitelist by adding additional classes that you want Groovy to access:

Groovy Whitelist

Groovy Source File





List of classes that Groovy can access. Enclose each classname in quotes and delimit each entry with a comma. For example:

def receiversWhiteList = [





The last entry shouldn't be followed by a comma.

Which classes you might restrict Groovy from accessing depends largely on your usage patterns, environment, and security concerns. Because of this, we can't provide specific advice about what you should whitelist. However, we have some general recommendations of classes you wouldn't or would want to whitelist.

For example, Groovy can be used to execute commands in the server host's operating system using a string literal such as rm -rf /".execute(). Therefore, java.lang.String shouldn't be added to the whitelist.

However, some classes, like those in the default list, are considered much safer. For example, the class org.apache.commons.lang3.StringUtils consists solely of static utility string methods, so if it's in the whitelist, you can call StringUtils.isEmpty() to check for an empty string, instead of calling isEmpty() on a string directly.

When you enable and configure the whitelist, be sure to test your JasperReports Server environment thoroughly.

If you have been running your server without this restriction, and then enable and configure it, some functionality may fail. For example, Domains that include a security file may return errors, since they rely on Groovy to evaluate the principalExpression. The failure is likely because the Groovy expression calls classes that aren't in your whitelist. However, your best course of action isn't necessarily to add those classes to the whitelist, as it may be difficult to debug. It's better to create a method in BaseGroovyScript and call it from the Domain security expression. For more information, please see our article on the Jaspersoft community site (

For more information about Groovy, see Apache's Groovy web site.