Hi Nilesh; Wrt thread safety, yes, JexlEngine and JexlExpression are thread-safe. Objects whose access is shared through scripts - your classes - must be too though. Btw, in your case, note that JEXL uses a (configurable thread-safe) cache for expressions which may mitigate your need for 'greedy' expression creation.
Wrt security, as of JEXL 3.3 - soon to be released -, the default permissions will restrict what a user can access to a very limited set of classes. Those are configurable and can be tailored (JexlPermissions/JexlSandbox/@NoJexl annotation). In JEXL 3.2.1, *by default*, any public class/method/field is accessible which ultimately allows all kinds of shenanigans. You can also restrict parts of the language to disallow constructs like side-effects (JexlFeatures). Hope this helps, Cheers On 2023/02/23 15:36:18 Nilesh PS wrote: > Hello Jexl users, > > First of all, thank you devs for building and maintaining this library. I > was about to give up my search for a simple expression evaluator when I > came across Jexl. > > I'm hoping to use Jexl in a web service to evaluate simple expressions. > Having tried out a few simple expressions successfully, a couple of > questions immediately came to mind. > > 1. Are classes like JexlEngine and JexlExpression thread safe ? I'm > running a spring boot service with one thread per request and have to > evaluate some expressions with the values given in the request. Would it be > safe to create a JexlExpression during service init and share it between > all request threads ? I'm hoping this would reduce the latency overhead > since the expression is parsed only once, but I couldn't figure out whether > it's safe to do so. > > 2. Are there any obvious security risks in evaluating expressions (not > scripts) that come from an external user ? I know this will heavily depend > on my implementation, but I'm hoping expressions are side effect free (e.g > no calls to System.setProperty allowed) under all circumstances so they can > be used with simple string and number inputs. > > Any inputs are appreciated. > > Thanks, > Nilesh > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
