-
-
Notifications
You must be signed in to change notification settings - Fork 428
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
Comments
+1 |
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. |
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. |
Looks to me like a duplicate of eclipse-archived/smarthome#575. |
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. |
@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. |
as the duplicative repo is archived - maybe this can be reopened? |
Yes, we can reopen it, although it won't bring us any closer to a solution. |
Same issue here. I'm not able to use a Nginx reverse-proxy if the url is a non-root location. |
Solves openhab#150 Signed-off-by: Martin Herbst <mail@mherbst.de>
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 |
Multiple things here:
|
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 Source: https://www.eclipse.org/jetty/documentation/jetty-9/index.html#setting-context-path |
@AxxiD I removed it. |
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. See also https://github.com/openhab/openhab-webui/issues/1290 |
This is my apache2 reverse proxy config. In debian save it to As mentioned before this will handle most UI requests but not all. The UI has to be aware of the changed server context path.
|
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 |
@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:
|
@mu88 sorry, can't help you there. |
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 |
Same here @mu88. Authentication doesn't work. I usually disable rest auth. |
Okay, thx for your feedback |
Dear @kaikreuzer is this issue likely to ever being addressed at all? |
Like with any other issue: If someone knows how to do it and provides a PR for it, it will be fixed, yes. |
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.
The text was updated successfully, but these errors were encountered: