Groovy Sandbox

Next to the older – and less feature rich – Excel-like formula syntax, Groovy code is the main means to configure Pricefx. Groovy as such is a full programming language which can be used to develop entire applications and generally “do anything”. However, in the context of using it for Pricefx configuration purposes, this “anything” has to be somewhat limited for a number of reasons:

• Security. It has to be avoided in all cases that malicious or dangerous code is injected and executed. This includes the topic about multi-tenancy of the environment. It must not be possible to break the barrier of a tenant and get to other tenants' data.

• Performance and Resiliency. This is primarily about preventing rouge or runaway jobs or calculations that (usually) accidentally run e.g. into infinite loops or work on much larger data sets than expected. This can have negative performance implications to other parts of the system, hence need to be defused.

• Ability to upgrade. Configurations – including Groovy code – should be easily migratable to new versions of Pricefx. Migration is handled by Pricefx, hence the expectation of the customers is that things keep on running as before. Which is absolutely fine. However, that in turn also requires a bit of a restriction on the freedom of arbitrary code.

So how do we address this? With a formula sandbox!

All Groovy code that is part of a formula logic is not executed as-is. It is instrumented at compile-time (e.g. to ensure timeout behavior against infinite loops) and it runs in an isolated environment that allows only a defined approach to interact with the Pricefx system – primarily via the famous “api” binding.

A part of this sandbox is also a restriction of the so-called whitelisted objects. Only objects of that type can be used directly inside the sandbox. Also, you cannot import other arbitrary classes or packages. The reasons for this is security: some default objects like “System” contain dangerous (from a system point of view) methods and ability to upgrade as any other classes that theoretically would be available to import can change on every version and would break the existing Groovy code.

The effect of these measures is that while you generally can use all syntax elements of Groovy (conditions, loops, operators, etc.), it does behave in some edge cases differently than a plain Groovy script you e.g. run locally. But the intention of Groovy in the context of Pricefx is not to expose a full customization option anyway. Its intention is to allow a familiar language to express business logic - NOT to customize the app beyond recognition.