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>
Without this configuration there are Spotless issues with line endings on Windows.
See: openhab/openhab-addons#8712
Signed-off-by: Wouter Born <github@maindrain.net>
* Added unit test for read-only Number- and String-Items to not return a Selection Element
* Improved usage of 'lastIndexOf'
Signed-off-by: Christoph Weitkamp <github@christophweitkamp.de>
This adds API tokens as a new credential type. Their format is:
`oh.<name>.<random chars>`
The "oh." prefix is used to tell them apart from a JWT access token,
because they're both used as a Bearer authorization scheme, but there
is no semantic value attached to any of the other parts.
They are stored hashed in the user's profile, and can be listed, added
or removed managed with the new `openhab:users` console command.
Currently the scopes are still not checked, but ultimately they could
be, for instance a scope of e.g. `user admin.items` would mean that the
API token can be used to perform user operations like retrieving info
or sending a command, _and_ managing the items, but nothing else -
even if the user has more permissions because of their role (which
will of course still be checked).
Tokens are normally passed in the Authorization header with the Bearer
scheme, or the X-OPENHAB-TOKEN header, like access tokens.
As a special exception, API tokens can also be used with the Basic
authorization scheme, **even if the allowBasicAuth** option is not
enabled in the "API Security" service, because there's no additional
security risk in allowing that. In that case, the token should be
passed as the username and the password MUST be empty.
In short, this means that all these curl commands will work:
- `curl -H 'Authorization: Bearer <token>' http://localhost:8080/rest/inbox`
- `curl -H 'X-OPENHAB-TOKEN: <token>' http://localhost:8080/rest/inbox`
- `curl -u '<token>[:]' http://localhost:8080/rest/inbox`
- `curl http://<token>@localhost:8080/rest/inbox`
2 REST API operations were adding to the AuthResource, to allow
authenticated users to list their tokens or remove (revoke) one.
Self-service for creating a token or changing the password is more
sensitive so these should be handled with a servlet and pages devoid
of any JavaScript instead of REST API calls, therefore for now they'll
have to be done with the console.
This also fixes regressions introduced with #1713 - the operations
annotated with @RolesAllowed({ Role.USER }) only were not authorized
for administrators anymore.
* Generate a unique salt for each token
Reusing the password salt is bad practice, and changing the
password changes the salt as well which makes all tokens
invalid.
Put the salt in the same field as the hash (concatenated
with a separator) to avoid modifying the JSON DB schema.
* Fix API token authentication, make scope available to security context
The X-OPENHAB-TOKEN header now has priority over the Authorization
header to credentials, if both are set.
* Add self-service pages to change password & create new API token
Signed-off-by: Yannick Schaus <github@schaus.net>
* Add rule UID to error message
* Add exception with stacktrace when debug level is enabled
Related to #1734
Signed-off-by: Wouter Born <github@maindrain.net>
(I included these fixes in #1735 but extracted them in a stanalone
PR because it's easier to review and a little more urgent.)
As a result of the refactoring in #1713, the operations annotated with
`@RolesAllowed` containing `Role.USER` are not anymore automatically
considered accessible to all users, regardless of their actual roles.
4 operations are therefore now denied to admins if they only have the
`Role.ADMIN` role, as the first admininistrator is created only with
that role the UI encounters unexpected access denied errors and breaks.
(See https://github.com/openhab/openhab-webui/issues/422).
Closes https://github.com/openhab/openhab-webui/issues/422.
Signed-off-by: Yannick Schaus <github@schaus.net>
* Allow basic authentication to authorize API access
Closes#1699.
Note, this opens a minor security issue that allows an attacker
to brute force passwords by making calls to the API - contrary to
the authorization page, the credentials parsing for the REST API
is stateless & doesn't have a lock mechanism to lock user accounts
after too many failed login attempts.
Signed-off-by: Yannick Schaus <github@schaus.net>
Xtext uses a cache for looking up classes when rules are run.
It also adds a null class value to this cache when a class is not found.
Once a value has entered the cache it will not be updated.
This causes the cache to return the wrong class (or the null value) when
calling static methods on ActionService and ThingActions classes that
were added/updated.
With the changes in this PR Xtext will be configured to use a custom cache
that updates the ActionService and ThingActions class references.
The PR also has a fix for the AnnotatedThingActionModuleTypeProvider not
properly sending ModuleType removed events when all ThingActions
registrations have been removed.
Fixes#1265Fixes#1694
Signed-off-by: Wouter Born <github@maindrain.net>
When one of the engines is unset the ScriptModuleTypeProvider clears all parameter options instead of only those that apply to that engine.
This fixes the Nashorn engine missing from the parameter options on the first openHAB startup.
Signed-off-by: Wouter Born <github@maindrain.net>
Catch specific exceptions and don't log errors but instead add an appropriate message and preserve the stacktrace.
Signed-off-by: Wouter Born <github@maindrain.net>
