Conversation
|
Just noticed that this also breaks the swarm view for a single bitaxe - it no longer detects itself. I will look into how to fix this |
|
The swarm page should now work again, with some limitations:
The swarm page still needs some cleanup. I think it would be best to only allow adding devices via ip addresses when the ui is accessed by ip to keep the old behavior and avoid confusion. Would appreciate quick feedback / input before I proceed with cleanup. |
|
We currently have #1240, which is planned for v2.13. If that is added, is this PR then still valid? |
|
According to the last comment it only covers .local, so this wont work behind a reverse proxy with a subdomain on a normal domain. I will close this PR and wait until the other one is merged, if this is still relevant I will open a new one based on the other PR. |
This allows the web ui / API to be accessed behind a reverse proxy with https. It also enables access by hostname (when the hostname resolves to a private IP address via LAN/DNS. This change does not add mDNS support).
It uses the standard X-Forwarded-For header behind a reverse proxy.
This header can be spoofed but this must be handled by the proxy (validating or stripping), not here.
The reverse proxy (immediate peer) must be on a private network and the client IP (from X-Forwarded-For) must also be from a private network.
This enables typical setups where https terminates at the proxy and the proxy forwards requests to the device over the local network. I tested it behind traefik and nginx.
Unfortunately i cant test swarm mode, but from what i saw in other PRs, I dont think swarm mode will work behind a reverse proxy if other devices are on an older firmware version.
ipv6 only proxies are not supported but ipv6 only networks are also not supported currently, so this should not be a regression.