Make openhab ui respect non-root base url

[altaroca]

The problem

as mentioned here openhab/openhab-core#150

it is often desired to run OH within the scope of an URL-path-prefix, i.e. not in the web-server's root (/).

As an example, imagine openhab is proxied to http://192.168.0.1/openhab to make it run beside other services like ZoneMinder at http://192.168.0.1/zm .

Using a reverse-proxy this can be mostly achieved. However there are still many parts in the ui that will try to access resources from the domain root (http://192.168.0.1/ in the example).

Your suggestion

I have a working solution at my end and will try to package it into a PR soon.

It works like this:

• apache2 reverse proxies all requests for http://192.168.0.1/openhab to http://localhost:8080
• the proxy also sets a cookie X-OPENHAB-CONTEXT-ROOT=/openhab
• the webui reads this cookie and adds a <base /> tag to the page
• this works fine for all relative urls. But there are many absolute urls scattered throughout the UI
• from the tag your browser will set property document.baseURI which is available everywhere in the UI
• any absolute url accesses, to say '/rest', in the UI have to be changed to document.baseURI + '/rest'
• there are many (a GREAT many) such accesses. So I only did this for a few difficult cases
• all other cases are handled by the reverse proxy again. The proxy basically catches any of the UI's run-away requests and redirects them to http://192.168.0.1/openhab again

Your environment

Not sure if that is relevant but I run openhab on raspbian buster, the reverse proxy is apache2 and I most often use chrome to access the main ui.

Additional information

[hubsif]

Hi! Partly being responsible for the current limitation (see starting this comment of PR #964), I think a maybe cleaner solution than using this clever cookie magic (👍) would be to make the subpath configurable and loaded from the backend, like it is the case with some other apps. So, if your solution works properly, the only change would then be to get the "X-OPENHAB-CONTEXT-ROOT" value from the backend instead of a cookie (or even have the backend inject it).

Also, I'd like to mention that the original issue "make it run beside other services" in my view doesn't fully exist, as this seems doable to me. With openHAB running at root level, you can still hook other services into subpaths, like mentioned in here. Though, I fully understand that the limitation to have to run openHAB at root isn't always desired.

[altaroca]

I actually like the idea of decoupling frontend and backend. In the proposed setup the backend does not need to know details of the proxy address. If I want to change the context path I only have to reconfigure the proxy. But maybe there is an option to set the cookie (or another piece of data) containing the context path from the backend and make it so it can be overridden from the proxy?

[hubsif]

In the proposed setup the backend does not need to know details of the proxy address.

Right, that also came to my mind. This would allow to still access the same OH instance in different ways, depending on whether there's a proxy in between or not.

In any case I started looking a bit into this and I think webpack's support for publicpath at runtime might come in handy and possibly provide a clean solution covering all different paths of mainui. Though, what still needs to be considered is all the additional UIs, like habpanel, habbot etc. Not sure right now how good their support is on path rewrites.

[davidgiga1993]

Just stumbled upon this issue, I'm a bit shocked OH never supported this since it is such a basic requirement for web applications. Nevertheless if I may provide some feedback: Setting a cookie for the UI feels wrong and has some caveats - mostly it doesn't work with all reverse proxies correctly and requires quite a bit of logic in the reverse proxy to handle cookie merging correctly.

Taking a look at a lot of other web applications out there, nearly all of them have a backend configuration parameter to define the absolute path the application is running under (for example publicPath).

Another point why the backend needs to know the public path of the application is notifications. Sending out any notification with a url requires the backend to know the public path it's reachable at, otherwise the links will just be wrong. Therefore I don't see this parameter as "frontend ony".

Passing this data to the frontend is as simple as injecting it into the static html page delivered to the requester. The frontend can then use this to correctly load dependent data/make api calls, ect.

[AshleighTheCutie]

Any updates on this?