Ability to provide arguments to getScriptEngine
sinaa opened this issue · 7 comments
Would it be possible to extend the library, such that it'd be possible to pass arguments to getScriptEngine
such as "-strict", "--no-java", "--no-syntax-extensions"
?
It'd be a great help since this library already provides sandboxing features such as CPU limits, etc.
Hi Sina,
Thank you for submitting this issue. I think it is always great to find ways to make the API more useful. Please see in the linked commit the change which will allow to create a new Sandbox as follows:
NashornSandbox sandbox = NashornSandboxes.create(args);
Could you point me to documentation what arguments are allowed? Could you think of a test case we could create to test this feature?
Thank you!
@mxro , thanks a lot for this!! really appreciate that you implemented the feature in the library.
Regarding documentation of the arguments, there's this official documentation ( http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/tip/docs/DEVELOPER_README ), but I don't know if there's a more accessible version of it.
Here's also some source reference to these properties: https://github.com/JetBrains/jdk8u_nashorn/blob/master/src/jdk/nashorn/internal/runtime/resources/Options.properties
There are quite a few options such as strict
, no-java
, no-syntax-extensions
, log
(log level), lazy-compilation
, etc.
Re. test cases, I'm particularly keen on --no-java
. Enabling it should make Java.XXX
not work.
Thank you for the information. I have added this to the documentation, creating a test case and released a new version to Maven central with the additional method in NashornSandboxes added.
I hope this solves this issue for you!
Thanks a lot. This is really great work. I'll update here if I find an issue in production.
Hello again.
Perhaps it'd make sense if I create a separate issue, but since it's relevant to this change, I comment here.
It seems that enabling strict mode has a conflict with delight. In particular, assertScriptEngine()
in NashornSandboxImpl
evaluates this expression:
quit=function(){};exit=function(){};print=function(){};echo = function(){};readFully=function(){};readLine=function(){};load=function(){};loadWithNewGlobal=function(){};$ARG=null;$ENV=null;$EXEC=null;$OPTIONS=null;$OUT=null;$ERR=null;$EXIT=null;
Would appending var
to the beginning of each global var above conflict with the library in any way? (is it intentional? would adding var
cause a problem?)
Thank you for reopening the issue and reporting this. I have changed the declaration of the variables. Can you test if this would work for you?
For testing, I could use scenarios in the following format:
-parameter
-script(s) what should no longer run.