Manual hostname for gateway

[oscar-b]

Running deCONZ and Phoscon with Docker using the marthoc/docker-deconz image. The instance is connected to an isolated network where Traefik is responsible for proxying. The problem I’m facing is that the discovery of the gateway announces the internal IP which isn’t reachable from the outside, only through the reverse proxy. I would like to be able to force the discovery to announce another hostname, to make this work.

Does that make sense, anything that would be useful for others? Or is there another way to do it?

[oscar-b]

Also related: #659

[oscar-b]

@manup I gave this another shot yesterday, and ran into a strange issue which I believe is a bug.

My attempted setup consists of deCONZ running in a Docker container (marthoc/docker-deconz) with two networks attached, homeautomation and proxy. These are private networks, not accessible from the outside, the idea is that services needing access to deCONZ API will run in the homeautomation network. For accessing the deCONZ web UI, you go through the reverse proxy, Traefik. This works fine, the trouble begins when trying to find the gateway:

1. The external call to the discover endpoint finds the gateway, however it reports the internalipaddress as the internal ip it has in one of the Docker networks. This is of course fine, there is no other way for it to find the correct way in, which is through the proxy. My suggestion is that it should be possible to manually specify a hostname that it should announce here instead.

2. After the discovery phase, the pwa webapp seems to start looking for the gateway in other ways as well, first of which seems to be an absolute request to /api/config, which is 100% correct in my case, since that hits the proxy and it gets a HTTP 200 back with the correct config. It also does failed requests to https://10.5.5.97/api/config and https://10.5.5.97:8080/api/config (my clients IP, why does it do that, and on a non-configured port?), and https://172.18.0.3/api/config (the internal Docker IP, so this is fine but won't work).

3. However, when clicking the discovered gateway, it tries to connect to https://deconz.proxy:80/api/, which won't work (notice https and port 80). The pwa app is loaded from https://deconz.proxy/ and thus using port 443. This seems like a bug, it shouldn't add port 80 here, which isn't even configured (web port is 2010 and ws port is 2011).

This seems to be related to the changes in #659, since // is used as the protocol now, it can be either http or https, dependent on how pwa is loaded. Using port 80 as a fallback won't work, I think it's safer to not fallback to a port at all if there is none (port 80 is the default for http anyway).

Please let me know if you want more info or configuration for setting up a Docker environment like this.

[oscar-b]

Temporary fixes:

In /usr/share/deCONZ/webapp/pwa, execute:

find . -type f -exec sed -i 's/| 80/| 443/g' {} +
find . -type f -exec sed -i 's/"80"/"443"/g' {} +

This will force port 443 instead of 80 as default (would be better to not defaulting to any port but this was easiest due to the minified files).

Next problem is websockets connecting with ws:// instead of wss://

find . -type f -exec sed -i 's/ws:\//wss:\//g' {} +

Haven't gotten the last part working yet, with Traefik.

[manup]

2. After the discovery phase, the pwa webapp seems to start looking for the gateway in other ways as well, first of which seems to be an absolute request to /api/config, which is 100% correct in my case, since that hits the proxy and it gets a HTTP 200 back with the correct config.

The first request is done by using the info of the browser url bar, I wonder why this isn't used in further login. I recon this should be the main issue to fix.

[...] It also does failed requests to https://10.5.5.97/api/config and https://10.5.5.97:8080/api/config (my clients IP, why does it do that, and on a non-configured port?), and https://172.18.0.3/api/config (the internal Docker IP, so this is fine but won't work).

One part of the discovery tries to use the ip addresses known to the browser, these can be queried via WebRTC. Based on that a local LAN search is possible which checks for gateways on port 80 or 8080.

The main purpose for this is to find gateways when they are not reachable via internet discovery.

This seems to be related to the changes in #659, since // is used as the protocol now, it can be either http or https, dependent on how pwa is loaded. Using port 80 as a fallback won't work, I think it's safer to not fallback to a port at all if there is none (port 80 is the default for http anyway).

I'll check the code, so basically the default fallback should be only host without port, so that browser can figure it out on it's own by http/https?

[oscar-b]

The first request is done by using the info of the browser url bar, I wonder why this isn't used in further login. I recon this should be the main issue to fix.

It is used, but adds port 80 to the URL which breaks it (it doesn't use this when testing the connection, but when saving it to localstorage I think).

I'll check the code, so basically the default fallback should be only host without port, so that browser can figure it out on it's own by http/https?

Exactly, tacking on port 80 doesn't do anything if it's already http, but is incorrect if it's https. So removing this shouldn't have any negative effect on anyone, the browser will just remove it anyway since it's the default port. If the protocol is https, the browser will use port 443 by default instead, same thing here, no need to specify it manually.

[manup]

Did 2.05.48 solve the issues?

[oscar-b]

@manup Sorry, I haven't had time to test this yet. Will try to find some time in the coming days.

[oscar-b]

@manup Running 2.05.49 now.

Upon load of pwa, it scans and finds my proxied deCONZ properly:

scanner worker init
add ip deconz.proxy
found gw: deconz.proxy 
add ip 10.5.5.97
found gw: deconz.proxy
add ip 172.20.0.4
found gw: deconz.proxy 
already have reachable gateways
found gw: deconz.proxy 
found gw: deconz.proxy 
found gw: deconz.proxy

It properly pulls the config from https://deconz.proxy/api/config and stores it in localstorage app.gateways as far as I can see.

When clicking the discovered unit, it sends a (preflight) request to https://deconz.proxy:2010/api/ (which fails) and kicks me to the login page. When trying to login it also sends the request this URL containing the port which also fails, it needs to go to :443 or no port at all, same as the other requests.

I guess one way to solve this is to configure the deCONZ port to 443 instead, which seems to work fine. Maybe that's good enough? In my case at least, it's no problem since I'm running it in Docker, but if you're sharing a server with multiple applications it's unlikely you can claim port 443 like that though (you probably have the reverse proxy running there).

There's also still the problem with wss:// but you wrote someplace else that would be solved in a later release. Currently it falls back manual poll.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[haecker-felix]

I also struggled with using the web app + traefik as reverse proxy, but I found a workaround. Maybe someone is interested:

dresden-elektronik/phoscon-app-beta#413