Related to #1791
Also-by: Christoph Weitkamp <github@christophweitkamp.de>
Also-by: Mark <m.stroeve@appsoftware.nl>
Signed-off-by: Laurent Garnier <lg.hc@free.fr>
I can't think of a good reason why listing things or querying their status should be allowed for users.
The things layer should only be of concern to admins IMHO.
As noted here: https://community.openhab.org/t/oh3-will-list-all-your-things-even-if-you-are-not-logged-in/108006/3
passwords and other sensible information in configuration could end up being exposed without auth required.
Signed-off-by: Yannick Schaus <github@schaus.net>
Remove the groupname from the members if the group item is removed.
This is implemented in the ManagedItemProvider.
Fixes#1785Fixes#1392
Signed-off-by: Simon Lamon <simonlamon93@hotmail.com>
The /things, /rules, /ui/components endpoints retrieve all objects
in their entirety, which can become very big, i.e. channels, config
parameters, script rule modules or trees of UI components can
quickly add up to the size.
When the UI simply displays a list of those objects it retrieves all
this extra information but does nothing with it.
This introduces an optional ?summary=true query parameter for the
above resources to limit the output to pre-defined fields which are
deemed most relevant for displaying these lists, omitting the rest.
When the option is not set, the behavior remains unchanged so this
change is not API breaking. The API version has therefore not been
incremented. The client is responsible for adding the option to
retrieve summarized collections instead of the entire objects.
Signed-off-by: Yannick Schaus <github@schaus.net>
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>
Some MQTT servers can be quirky, then do not handle Usubscribe request properly.
In this case we have to omit sending it. Introduce a boolean flag, telling
whether the request should be sent or not, and add a public function to set it.
iRobot built-in MQTT server is known to suffer from this problem.
Signed-off-by: Pavel Fedin <pavel_fedin@mail.ru>
These workarounds to prevent false positives can be removed now the EEAs allow for proper null analysis.
Signed-off-by: Wouter Born <github@maindrain.net>
