Bindings/Services: Own html endpoints


(David Graeff) #1

Hello developer community,

this is one of a few Ideas I like the AC to consider.

Some bindings, like the ZWave and Zigbee one and also MQTT, but also some services like the Hue emulation are in need of a custom status report page.

Use cases

For ZWave/Zigbee that is for example a Mesh representation (see also Habmin), for MQTT a realtime log of received and matched topics. For the hue emulation a self-test report page with a detailed list of exposed items and current known clients to debug if Amazon Echos have indeed tried to register for example.

We can now model dozen of APIs to somehow allow all possible data streams and on the UI side implement dozen of widgets to render those.

Proposal: Own html endpoints

My proposal is instead to allow bindings and services to register their own endpoint in a standardized way, for example “http://my-openhab:80/extension/hueemulation” or “http://my-openhab:80/extension/mqtt.generic”.

Services/Bindings are then allowed to ship own html content on those endpoints. If we correctly configure Jetty this will not be a security risk, even if the binding is somehow malicious:

The use of the http headers X-Frame-Options and Content-Security-Policy and X-Content-Type-Options and X-XSS-Protection will prevent any external calls / embedding of external content or spying on a master document that embeds such html pages.

The html pages should be self-contained, no external fonts, no external javascript, and follow kind of a contract on how to style elements (for example annotating all <button>s with “btn” classes etc.)

How to present those endpoints

A future UI would iframe-embed or XHR-embed those pages. I have made a proposal for trying out what I suggest in my Paper UI NG design study:

Bildschirmfoto%20vom%202019-02-12%2017-32-46

What about textual only users

The proposed pages are presenting an extended status that you need to visualize. The console is not enough or extremely hard to support (I mean, everything is possible, imagine an ASCII rendered ZWave mesh, but nah…). This proposal is to reduce help requests on the forum, where in the MQTT case for instance a typo in the command/state topic is periodically causing a 20 posts long find-the-problem thread. Pros (textual users) don’t do such mistakes.

Cheers, David


(Hilbrand Bouwkamp) #2

Don’t forget OAuth callback pages that get parameters passed back from external services to a local servlet, see the spotify pr.


(Rich Koshak) #3

Well, at least they are able to find it when they make such mistakes on their own. :wink:

I’ll open a corresponding AC thread.

I’m a little more ambivalent on this one. I agree that this is a problem and who is best to build such a binding specific UI/viewer than the binding developer themselves. However, I worry about a proliferation of UIs all with different maintainers which might get out of hand.

Is there a way we can do more than just offer a contract but instead offer a skeleton to build upon? Would the binding reviewers know enough about web and javascript to review and enforce the contract on these widgets? I know we have a lack of reviewers and I fear adding an additional burden on them for review could exacerbate the problem of timely approval of new bindings.


(YvesHanoulle) #4

Well, at least they are able to find it when they make such mistakes on their own.

if that info is also somewhere in log files, which I assume it alway is.


(David Graeff) #5

You are right on this one, and that’s why I like a decision from the AC and a discussion. But look at habmin and the really good zwave support in there. This is possible with custom html / widgets and reviewers would need to review just somewhere else.


(Yannick Schaus) #6

I think it’s a good idea.
However, not trying to embed those specialized UIs in a main UI’s page could be even easier, and more flexible, since such an specialized UI could need complex mix of Javascript libraries to do what it has to do - for instance rendering a Z-Wave network graph… so why not give them that latitude and keep them self-contained? See for example the REST docs.

Any bundle (including a binding add-on) already has the ability to register static content in Jetty with HttpService.registerResources() - and even add a tile in today’s dashboard, like UI add-ons do.
So if a binding comes with a full specialized web app, like a network graph, all we would need is to design an API wrapping this registerResources() to better control the URL namespace (like, limit it to /extensions/<name>/whatever) and how/where it would be presented in the main UI - that could be a simple link, a menu item, or an iframe. If however we decide to embed them in a page of the main UI after all, then web components could be the way to go.


(David Graeff) #7

Yup exactly, that’s what the Amazon binding is doing for example. Or the hue emulation service for the debug screen.

This proposal is two-folded:

  1. A standard way to expose such services would be very helpful, I think.
  2. A REST endpoint (with “label”+ “description”+“url”) that lists all those pages or alternatively (like I have modeled it in Paper UI NG design study) those custom pages are listed within the REST response for a service/binding/thing.

(Łukasz Dywicki) #8

If you don’t want to run into troubles I think that’s good approach. It gives people a predictable way of A) where their things are available B) allow further unification of extensions.
One of prime examples I can bring from real world is “Atlassian Gadgets”. If you know how JIRA and other dashboards in their projects looks a like - all these are mixture of javascript, osgi and http resources. End developer is insulated from platform “internals” by most of the time.


(Rich Koshak) #9

There is already an issue open for this topic. If the maintainers cannot come to a consensus on/how to handle this then I think this can be raised to the AC again to help with the impasse. In the mean time this is not within the scope of the AC. So please carry on. :slight_smile: