* New translations addons.properties (French)
* New translations audio.properties (Hebrew)
* New translations audio.properties (Hungarian)
* New translations chart.properties (Finnish)
* New translations chart.properties (French)
* New translations ephemeris.properties (Hebrew)
* New translations firmware.properties (Finnish)
* New translations i18n.properties (Hebrew)
* New translations inbox.properties (Hebrew)
* New translations jsonStorage.properties (French)
* New translations LanguageSupport.properties (Finnish)
* New translations network.properties (Hebrew)
* New translations persistence.properties (French)
* New translations persistence.properties (Hebrew)
* New translations SystemProfiles.properties (Hebrew)
* New translations tags.properties (Hebrew)
* New translations voice.properties (Hebrew)
* Added marker interface for TriggerHandler to indicate if they are time based and thus can be used to simulate execution times.
* Added marker interface for ConditionHandler to indicate, if they are time based and thus can be checked during rule execution for a certain time.
* Moved CronAdjuster to common, so it can be used for the rule simulation
* Created RuleExecutionSimulator that allows simulation of rules
* Added method in RuleManger to create simulation
* Added rest endpoint for rule simulation.
* Changed marker interface to return TemporalAdjuster instead of cron expression. This better hides the internals of the TriggerHandler (i.e. the cron expression) and is more clear and flexible for other handlers to implement
Fixes#2044Fixes#2266
Signed-off-by: Sönke Küper <soenkekueper@gmx.de>
Some users reported the scheduler to be run to earlier.
It actual is known the Java scheduler can drift.
To handle this problem 2 changes have been made:
1. If the scheduler triggers > 2 sec before expected end time it will
reschedule.
2. The scheduler keeps track of the timestamp the job should run. For
recurring schedulers, like cron, when the next job is run it offsets of
the calculated time, and not the actual time. This guaranties that the
next scheduled time is actual the next scheduled time and not the same
end time in case the scheduler would trigger to early.
Signed-off-by: Hilbrand Bouwkamp <hilbrand@h72.nl>
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>
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>
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>
