rlkoshak
September 12, 2016, 6:06pm
2
JavaScript is only supported through the JSR233 binding. There is an Experimental Rules addon you can install after enabling Experimental sources in PaperUI. I think that supports JavaScript.
I also think that the JSR233 binding can be installed using the openHAB compatibility layer, but am not sure it completely works.
Watch the following issue on GitHub for progress on enabling authentication. Alternatively yes, use a reverse proxy or my.openhab.
opened 10:23AM - 03 Dec 15 UTC
enhancement
Core
help wanted
migrated from Bugzilla [#423548](https://bugs.eclipse.org/bugs/show_bug.cgi?id=4… 23548)
status NEW severity _enhancement_ in component _Core_ for _---_
Reported in version _unspecified_ on platform _PC_
Assigned to: Project Inbox
On 2013-12-08 15:16:18 -0500, Kai Kreuzer wrote:
> Migrated from https://code.google.com/p/openhab/issues/detail?id=387
On 2015-09-25 03:52:04 -0400, Kai Kreuzer wrote:
> Some input from my side what I see should be covered. There are multiple levels of access control that can be addressed:
> 1. Global access control as it is done in openHAB 1 (see https://github.com/openhab/openhab/wiki/Security#authentication). I.e. for any access to the runtime, the user needs credentials and is then assigned a role.
> JAAS is probably a good option here. Note that the solution has to work in general for any OSGi HttpService, it must not be specific to Jetty (while in openHAB 2, we can add a Jetty-specific configuration for JAAS then).
> 2. Restrict certain urls and/or http verbs for certain roles. See the example discussed in https://www.eclipse.org/forums/index.php/t/1068387/.
> 3. Restrict access on certain data, e.g. return a HTTP 403 when my kids try to access localhost:8080/classicui/app?sitemap=admin. This could be implemented in phases, the most important resource would be sitemaps, then come items, things, rules, etc. But in general this mechanism should be available on all resources. Configuration of such restrictions should not only be by resource name, but possibly also by type/tag, e.g. do not grant access to any item that is tagged as "security".
> 4. Filter data within requests, i.e. if I do not have rights for sitemap "admin" (see 3), the REST url /rest/sitemaps should not even list it. Sitemaps that refer to items that I am not allowed to access should filter out these widgets automatically.
> 5. Check implications on automation rules. Normally, rules are executed by the system and not the user. But we could imagine that a trigger was caused by some user (e.g. an item state change) and thus the rule could be regarded to be executed on behalf of this user - then again, the permissions should be checked and e.g. sending commands to restricted items must be blocked.
>
> Does anybody has further ideas/requirements?
I thought that bug was fixed in the latest build. I haven’t see that error yet.
If you use the 1.9 bindings in OH 2, you can use your existing Items files and Rules almost as is (you may need to remove some imports in your rules files). I am successfully doing this and have documented the procedure here:
This Tutorial is Deprecated. Please see the Official Docs
I’ll leave this content up for posterity but please use the official docs. It has been significantly updated with new sections including how to configure using addons.cfg and runtime.cfg.
I am starting the migration from OH 1 to OH 2 with the intent of both upgrading my deployment and creating a tutorial for the official OH 2 docs.
I tend to be very thorough and deliberate so this may take a few days and it might become longer than ne…
Its a work in progress though.
Yes.
1 Like
