Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
nlmarco opened this issue May 17, 2017 · 24 comments
Open

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

nlmarco opened this issue May 17, 2017 · 24 comments

Comments

@nlmarco
Copy link

nlmarco commented May 17, 2017

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
Copy link
Member

+1

@alabamatoy
Copy link

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
Copy link

ikke-t commented Aug 9, 2017

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
Copy link
Member

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

@alabamatoy
Copy link

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
Copy link
Member

@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
Copy link

rajwitt commented Jul 7, 2020

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

@kaikreuzer
Copy link
Member

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

@kaikreuzer kaikreuzer reopened this Jul 7, 2020
@Conobi
Copy link

Conobi commented Sep 10, 2020

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

Rosi2143 pushed a commit to Rosi2143/openhab-core that referenced this issue Dec 26, 2020
Solves openhab#150

Signed-off-by: Martin Herbst <mail@mherbst.de>
@openhab-bot
Copy link
Collaborator

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
Copy link

AxxiD commented Jan 2, 2022

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
Copy link

msteiger commented Jan 8, 2022

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
Copy link
Member

@kaikreuzer Is the label duplicate still applicable?

@AxxiD I removed it.

@altaroca
Copy link

altaroca commented Jan 29, 2022

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
Copy link

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
Copy link

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
Copy link

mu88 commented Nov 28, 2022

@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
Copy link

@mu88 sorry, can't help you there.

@openhab-bot
Copy link
Collaborator

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
Copy link

mu88 commented May 20, 2023

@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
Copy link

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

@mu88
Copy link

mu88 commented May 27, 2023

Okay, thx for your feedback

@mu88
Copy link

mu88 commented Jul 29, 2023

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

@kaikreuzer
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests