[feat] Support for reverse proxy

[Gsyltc]

With the evolution of practices and container-based solutions (Docker, Kubernetes, Swarm, etc), reverse proxy services (Treafik, Nginx ingress) are used. Would it be possible to take these developments into account?

Describe the solution you'd like Add a new environment variable to change the default path of the web application.

Example: :

Let's consider 3 front-end applications in containers:

• Zwave2Mqtt
• 1 home automation solution 'Home Assistant, Domoticz, or Jeedom)
• Grafana (services like prometheus, influxDb implements in back-end) ;

1 domain name: https://my.domain.ovh

the address https://my.domain.ovh is linked to the home automation solution https://my.domain.ovh/zwave2mqtt is linked to zwave2mqtt the address https://my.domain.ovh/grafana is linked to Grafana

The whole thing is managed via load balancing software with reverse proxy and ingress, etc... (ex: traefik).

The goal would be to be able to add an environment variable so that the root of the website can be configured.

Currently, if we use a reverse proxy with a "PathPrefix", the application can't find the js files.

Somes pictures to illustrate :

Thanks you

[robertsLando]

@Gsyltc I'm ok for this. Would you mind to submit a PR?

[Gsyltc]

Unfortunatly, I haven't good knowledge with Javascript. I don't have the expertise to make changes and the PR. But I can send you all informations and resources to make changes.

Actually, I can see one things 👍

My entrypoint for all services is on port 80 When I configure zwave2mqtt with / redirection, it works. The site (port 80) is redirected on the service (port 8091).

When I configure with the path "/zwave" (or /zwave/) I have a blank page. It means the index.html pages is find. If not, redirection is on the principal website (the Automation application for exemple, Or a 404 code). but I see a thing with the file called site.webmanifest. It seems the file want to call some things on port 80. I try to override process.app.PORT with port 8091, but it doesn't work .

For help, there is the requierement 👍 The web application must be able to have a relative path in all these links (html, css, js) so that if you want to use the application you can do it like this http://192.168.X.X:8091/ in normal configuration

example with a customized configuration http://192.168.X.X:8091/my/personalized/path my/personalized/path is a variable that can be configured.

this must works without reverse proxy or anything else. The site must be able to react in this way natively. With this requierement, it will then be possible to make the necessary redirections. If you wish that I can look and make the tests, I can try eventually, but I would need tracks to know where to start and what are the elements that I have to check. But I don't promise success. lol

[robertsLando]

@Gsyltc this need some thoughts...

[chrisns]

@Gsyltc this is more an issue for your proxy, you should be able to have it rewrite the content

as an alternative you could perhaps have a different hostname rather than a sub-path?

[fabio-torchetti]

I have a PR #540 that is working enough to have the WIP tag removed soonish. The approach I used has been to expose the main index page dynamically, so that the paths of the bundles can be determined on the fly. Figuring out the websocket namespace vs path took me a while longer.

I am currently using it behind the HA ingress as an integrated side panel and seems to be doing fine - I see a couple of issues on the zwave network side, but they don't seem to be related to the web interface changes.

I moved to zwavetomqtt after trying the integration with the recommended zwave to mqtt bridge, but that misses all of the needed management interface. Looking forward to bypassing the mqtt discovery and using the new MQTT ZWave messaging.

[chrisns]

think this can be closed thanks to #540 please reopen if i'm wrong