Introduce URL-path-prefix (hard-coded at least)

[nlmarco]

As already mentioned in

https://community.openhab.org/t/using-nginx-reverse-proxy-authentication-and-https/

and

https://community.openhab.org/t/apache2-reverse-proxy-with-ldap-authentication-https-and-url-path-prefix/

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

It would be great, if the URL-path-prefix was configurable, but if this is very hard to achieve, at least a static, hard-coded path-prefix would be better than the current situation. Currently, OH runs in the web-server's root.

Rewriting many individual paths is very error-prone, likely never complete, and bloats the configuration. If there was at least a hard-coded path-prefix (e.g. "openhab/"), then one single SUBSTITUTE-rule would be sufficient to reliably remap everything.

People who want to use the root, e.g. to conveniently go to just https://host/ (instead of https://host/openhab/) could still do this easily by configuring redirects. These redirects would be necessary only for one or at most a hand full of entry-points. Thus, a single hard-coded path-prefix would IMHO be clearly preferable over the current situation.

[AngelosF]

+1

[alabamatoy]

Please make it so. The current design effectively prevents running openhab behind a proxy which supports other systems simultaneously. While it may be possible to write all of the substitution and rewrite rules to make it work in the current design, the result is an extremely fragile implementation which will be broken by any subsequent changes to the query string formatting or URI. The solution suggested by nlmarco would result in a far simpler configuration that would survive upgrades and changes.

[ikke-t]

For starters it could be enough to add env variable or config option for domain (example.com) and suffix (/home/oh) variables, which would be used as prefix for all internal app links, as well as css and such. This could be openhab wide, not only component like Basic UI, but it could be started to use component by component.

Here is an example how it's configured in Grafana: http://docs.grafana.org/installation/behind_proxy/

This is very normal conf option to have in web apps, and would be useful for OpenHAB. It helps protecting private installations in conveniant way.

An other more sophisticated way would be reading the request URL and adapt to it while running.

[kaikreuzer]

Looks to me like a duplicate of https://github.com/eclipse/smarthome/issues/575. Note that I doubt that this is easy to solve - otherwise somebody most likely would have fixed it since 2013...

[alabamatoy]

Why was this closed? Maybe "closed" here doesnt mean what it means in my configuration management world, but in my experience closed means nothing is going to happen, because its a non-issue. A number of people have asked to have this solved, and closing it seems to deprioritize it.

[martinvw]

@alabamatoy note that openHAB uses eclipse smart home as an underlying framework, so the issue above is the one to go for the actual status.

[rajwitt]

as the duplicative repo is archived - maybe this can be reopened?

[kaikreuzer]

Yes, we can reopen it, although it won't bring us any closer to a solution.

[Conobi]

Same issue here. I'm not able to use a Nginx reverse-proxy if the url is a non-root location.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-behind-apache-reverse-proxy-is-webroot-configurable/127826/8

[AxxiD]

Multiple things here:

1. @kaikreuzer Is the label duplicate still applicable? IMO it's not. Especially since the other issue seems to be in an archived repository and has not been solved. 🤔

2. The referenced commit by Rosi2143 does not solve this and seems completly unrelated to this issue. 😞

3. I'd really like to see some progress since this has been open for so long and I really need it for my own setup. The easiest way to configure it - I think - would be via an environment variable.

4. If this is not being put forward: Are there any workarounds avaiable? I haven't found any.

[msteiger]

I think that setting a global context path in Jetty should fix the URL path issues with the reverse proxy, because Jetty will prefix all generated URLs with a given value. Maybe something like ...

<Configure class="org.eclipse.jetty.webapp.WebAppContext">
  <Set name="contextPath">/openhab</Set>
  ...
</Configure>

can be put in the config here: https://github.com/openhab/openhab-distro/blob/main/distributions/openhab/src/main/resources/runtime/etc/jetty.xml

I don't know how to test this though. If it works, it would be nice to have this setting available as config entry (maybe in /etc/default/openhab ?).

Source: https://www.eclipse.org/jetty/documentation/jetty-9/index.html#setting-context-path

[kaikreuzer]

@kaikreuzer Is the label duplicate still applicable?

@AxxiD I removed it.

[altaroca]

A reverse proxy will map the server urls just fine. No need to touch the openhab server.

The problem is with the UI. It is not aware of the changed server urls and thus will always try to fetch things from the domain root.

I have a working solution at my end and will try to package it into a PR soon. 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 .

See also https://github.com/openhab/openhab-webui/issues/1290

[altaroca]

This is my apache2 reverse proxy config. In debian save it to /etc/apache2/sites-available/010-openhab.conf and run `a2ensite 010-openhab.conf. You can probably achieve the same with other proxies, but I wouldn't know how.

As mentioned before this will handle most UI requests but not all. The UI has to be aware of the changed server context path.

<VirtualHost *:80>
        
	RewriteEngine  on
        # if referrer is /openhab then the URL has to start with "/openhab" (redirect)
        RewriteCond	"%{HTTP_REFERER}" 	".*/openhab/.*"
        RewriteCond	"%{REQUEST_URI}" 	"!^/openhab/"
        RewriteRule	"(.*)"			"/openhab$1" [R=307,L]

        # uncomment to debug URL rewriting
        #LogLevel alert rewrite:trace3

        ProxyPass /openhab/ http://localhost:8080/ flushpackets=on
        ProxyPassReverse /openhab/ http://localhost:8080/

        <Location /openhab/>

		# set context path cookie if it does not not exist
		RewriteCond %{HTTP_COOKIE} "X-OPENHAB-CONTEXT-PATH"
		RewriteRule "(.*)" "$1" [E=oh_cookie:1]
		Header add Set-Cookie "X-OPENHAB-CONTEXT-PATH=/openhab"  env=!oh_cookie

		# rewrite absolute urls in JS etc.
                AddOutputFilterByType SUBSTITUTE text/html
                AddOutputFilterByType SUBSTITUTE text/css
                AddOutputFilterByType SUBSTITUTE application/javascript
                AddOutputFilterByType SUBSTITUTE application/json
		SubstituteMaxLineLength 5M
		
		# needs static hostname before apache 2.5.1
		Substitute "s|(://192.168.0.1/)(?!openhab/)|$1openhab/|"
		
        </Location>
        
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
        
</VirtualHost>

[msteiger]

Truly impressive! I wasn't aware that Apache could do such hacks and rewrite content like this. That said, I believe we should try and support this in OpenHab itself.

I believe that setting the context path in Jetty should make it prefix URL paths and set the baseURI correctly. I guess we would need to fix a few corner cases with hard-coded absolute root-based paths here and there as @altaroca mentioned.

[mu88]

@altaroca I'm trying to accomplish the same with nginx. Did you try this as well or have a clue how to do it? At the moment I have the following nginx config:

location /openhab/ {
        proxy_redirect off;
        rewrite ^/openhab/(.*)$ /$1 break;
        proxy_pass         http://localhost:8080;
        proxy_set_header   X-Forwarded-Host $host;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_pass_header  Content-Type;
    }```

[altaroca]

@mu88 sorry, can't help you there.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/use-tls-for-openhab-in-docker/141752/1

[mu88]

@altaroca does authentication work with your Apache configuration? If yes, it would help me very much if you could share a recorded browser session with the included network requests - because with my current prototype (based on YARP, see here), the URL path segment gets lost when authenticating

[altaroca]

Same here @mu88. Authentication doesn't work. I usually disable rest auth.

[mu88]

Okay, thx for your feedback

[mu88]

Dear @kaikreuzer is this issue likely to ever being addressed at all?

[kaikreuzer]

Like with any other issue: If someone knows how to do it and provides a PR for it, it will be fixed, yes.