move main ui to a sub path (instead of /)

[hdavid]

Hello,

in OH2 the ui was under /paperui/index.html, but now the new ui (which is great by the way) lives at the root (/) of the server. This makes it totally impossible to put openhab behind reverse proxy. a typical use case is : having grafana and openhab on one server, and exposing these services thru apache/nginx.

Could the ui be hosted under a folder of some kind ? for instance /oh/*

Cheers

[kaikreuzer]

There was a very fruitful discussion in the forum and I think the suggested solution to use virtual domain names is pretty clean and least error-prone. I hence don't think it is worth to put much effort into this issue here, wdyt?

[hdavid]

i agree the virtual domain offers a good solution. However having the ui not using absolute path, or being able to prefix the ui with a path would come handy to many users and render openhab more user friendly. i will find a way to make it work with domains but it might out of reach for many users.

[hubsif]

Hi! I'm working on #710/#964 and Yannick made me aware of this here.

This makes it totally impossible to put openhab behind reverse proxy. a typical use case is : having grafana and openhab on one server, and exposing these services thru apache/nginx.

I understand the goal is to have access to all OH services and UIs, combined with e.g. grafana, served from the same (reverse proxy) server. While I agree that having the main UI located under a certain subpath could make life easier for some people, I don't fully understand its requirement here: Couldn't the reverse proxy simply be configured, so it:

• forwards all requests going to /grafana to the grafana server
• forwards all other requests (/) to OH3

I think like this any additional service could be hooked into the OH service. The only thing to take of is to not use subpaths already used by OH (like /rest or /habpanel).

What am I missing here?

[hdavid]

Hi,

i will comment, from the point of view of my use case. Ideally i would have one domain, forwarding to different backend services including a website, grafana, and openhab, node.js etc. I would put each service under its own path, reverse proxied by apache or nginx, over HTTPS and with a global level of authentication handled by apache/nginx (as the server is exposed to the internet).

In the end i went for a sub domain for OpenHAB, as i could not figure out all the paths that should be forwared. In the case of grafana, it was easier, as it supports this feature out of the box: https://grafana.com/tutorials/run-grafana-behind-a-proxy/

There is an other aspect that makes that a little difficult in the case of openHAB; authentication. Somehow, the authentication of openHAB collides with the basic auth of Apache (it seems to be easier to handle with nginx). i got it to somehow work so my setup.

It works, but it would be so much nicer if openHAB could be configured in a similar way to grafana. that said, i would totally understand it is not an easy thing to acheive.

About the two tickets mentioned in your comments, i did noticed that middle clicking some links from the menu would indeed cause some 404 errors, and it seems this would fix it. and maybe fixing these tickets would allow to have configurable base base for openhab ?

feel free to hit me if you want to chat about it mots at motscousus.com

cheers,

Henri

[hubsif]

Thank you, @hdavid, I understand your point. Though, I think you still kind of left the actual question unanswered: Why do you need OH to run under a subpath for this? Just because it's "cleaner" to have each under its own? Or do you want to place something else under root ('/')?

Anyway, the changes in #964 would actually make things even worse for you 😬. I'm going to comment there soon, please follow up there.

[hdavid]

hi @hubsif, you are right, sorry! Yes because it is cleaner, but also easier, and avoid some trial and errors to find all the used paths. It also would make it more future proof: upgrading openhab could add new paths that would make things to silently fail and require adjusting the reverse proxy config. All in all it would make it the whole thing much cleaner and easier to manage. i will watch #954 :)

[hubsif]

It also would make it more future proof: upgrading openhab could add new paths that would make things to silently fail and require adjusting the reverse proxy config.

Well, from the title of this issue this would still apply: Since this issue is only about moving mainUI to a subpath, upgrading openHAB could still add new paths, only those added in mainUI wouldn't matter.

Though with the change introduced in #964 and mainUI not being subpathed, you'd now have to add a lot of mainUI pathes to the proxy list, since ProxyPass /openhab/ http://127.0.0.1:8080/ alone wouldn't do anymore. Latest then, I'd have a general rule at the end that simply forwards all remaining subpathes to openhab (as in `ProxyPass / http://127.0.0.1:8080/), in the end having something like this:

ProxyPass /grafana http://127.0.0.1:<grafanaport>/
ProxyPass /someotherservice http://127.0.0.1:<someotherport>/
ProxyPass / http://127.0.0.1:8080/  <-- openHAB

Which would lead to http://myserver/ hitting the mainUI, http://myserver/grafana going to grafana and e.g. http://myserver/habpanel to HABpanel. To me that sounds like a fairly clean solution. The only difference and advantage of mainUI being subpathed would be to not having to take care of not proxypassing mainUI's subpathes (e.g. /page), like you mentioned above.

[DarkC35]

Sorry to bug in but I don't really understand why a sub path is needed when you use a reverse proxy like nginx? Wouldn't it be easier to just play around with the ports of your services (and OH does support to change the port if 8080 conficts with one of your other services) since such a sub path feature does not seem to be a standard feature a webservice normally offers IMO. So a possible solution (pseudo code since I'm not that familar with nginx) could be something like this:

server {
  listen 80;

  location /grafana/ {
   proxy_pass http://localhost:3000/; # when 3000 is your grafana port
  }
  location /oh/ {
   proxy_pass http://localhost:8080/; # when 8080 is your OH port
  }
  location /someotherservice/ {
   proxy_pass http://localhost:5000/; 
  }
}

Sorry if i misunderstand the scope of the issue here.

[hubsif]

@DarkC35 You're right, usually it's as easy as what you suggested. But that only works if the site proxied uses relative paths, i.e. when it loads e.g. an image from images/myimage.png the path of this image must not be absolute. If it's relative, the browser converts it to <current_host>/<current_path>/<image_source>, in your example <current_host>/oh/images/myimage.png. The proxy then rewrites and forwards that according to its rule.

However, if the paths requested are absolute, e.g. /images/myimage.png, the browser uses them as is. The example then results in the browser requesting for <current_host>/images/myimage.png. This path is invalid, as it doesn't contain the /oh/ for the proxy to match the openHAB rule.

While what you suggested should currently be possible with openHAB's mainUI pages, it might still not fully work as the UI requests data from the absolute path /rest. So, at least this path (and maybe others) would be required to be forwarded by the proxy as is (location /rest/ { proxy_pass http://localhost:8080/rest/; }).

Now, with the upcoming change in #964, the mainUI will only use absolute paths, with the result that it cannot be remapped (to e.g. /oh/) anymore. It can still be proxied, but only without a path change (i.e. location / { proxy_pass http://localhost:8080/; }. You could also still plug other services like grafana, but the subpath used may not be already utilized by mainUI (e.g. location /grafana/ { proxy_pass http://localhost:<grafana_port>/; } would work just fine, while /settings/ wouldn't).