mirror of
https://github.com/danieldemus/openhab-core.git
synced 2025-01-11 05:41:52 +01:00
4e045204ac
This should fix the issue reported here: https://community.openhab.org/t/openhab-3-0-milestone-2-discussion/107564/8 where the Nashorn script engine would be created with the current thread's class loader, causing JS code like this: ``` var Log = Java.type("org.openhab.core.model.script.actions.Log"); Log.logError("Experiments", "This is an OH error log"); Log.logWarn("Experiments", "This is an OH warn log"); Log.logInfo("Experiments", "This is an OH info log"); Log.logDebug("Experiments", "This is an OH debug log"); ``` to run fine when the rule was triggered but fail to find the Log class when run from the REST API's `/rest/rules/{ruleUID}/runnow`, because in that case the generic createScriptEngine implementation would return script engines using the JAX-RS class loader as the "app" class loader. Note: We also have an opportunity to restrict which classes are exposed to the script with a ClassFilter to a specific set: https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/NashornScriptEngineFactory.html#getScriptEngine-java.lang.String:A-java.lang.ClassLoader-jdk.nashorn.api.scripting.ClassFilter- This could prove useful to mitigate code execution vulnerabilities, as the script code is modifiable remotely. Signed-off-by: Yannick Schaus <github@schaus.net> |
||
|---|---|---|
| .. | ||
| src/main/java/org/openhab/core/automation/module/script | ||
| .classpath | ||
| .project | ||
| bnd.bnd | ||
| NOTICE | ||
| pom.xml | ||