Dashboard Clock doesn't quite work behind the reverse proxy
In 8e1b9c22 I've added the possibility of optionally including the dashboard clock in the reverse proxy.
Setup
The relevant components (dashboard, dashboard-clock and engine-api) are set-up as follows:
- The dashboard-clock image contains a very simple nginx, deploying the files for dashboard-clock under port 5001. The bind-address can be configured, so this can bind to a private network if dashboard-clock shouldn't be world-readable
- Engine-API will bind to a private network. Only the two public endpoints (
trackservice
andtrackservice/current
) will be world-readable via the reverse proxy (this is not implemented yet). - The dashboard image contains a nginx-server which deploys dashboard and acts as a reverse-proxy for some further services (e.g. steering, tank). With a special env-variable set (INCLUDE_CLOCK, defaults to false) it will also act as a reverse proxy for dashboard-clock, thus making it world-readable (under $hostname/clock).
Dashboard-clock will fetch info from Engine-API via its clock
-endpoint. Because dashboard-clock is working completly client-side, the clock-endpoint needs to be reachable from the browser with which you're looking at the dashboard-clock.
Expected behavior
Now when I set INCLUDE_CLOCK to true, I'd expect dashboard-clock to be fully working from $hostname/clock. This means it should send requests to engine-apis clock
-endpoint and display the results.
Actual behavior
Now we run into multiple problems.
Engine-API is in a private network
Since engine-api is in a private network and the clock
-endpoint doesn't get exposed, it simply won't be reachable from the client accessing /clock
(except if that client is in the same private network)
Engine-API doesn't do https
If dashboard is configured to use https (which it does by default) or is in general accessed by https (which it should do in production), we'll even run in problems when engine-api is reachable from the accessing client. Engine-API doesn't do https and the /clock
endpoint isn't included in the reverse proxy.
Thus, when opening dashboard-clock, we'll be making request from an https site (dashboard-clock) to a http resource (the API), which will result in Blocked loading mixed active content “http://$hostname:8008/api/v1/clock"
-errors. This is sensible behavior.
Possible Mitigations
Generally this won't happen if engine-api is reachable from the client and dashboard is configured to http-only. Of course this is not really a safe configuration. In addition I'd argue, that for this you could just not bother with the proxy and access the clock from $hostname:5001.
Basically the only way for this to work reliably is to also make the /clock
-endpoint public. This could be an optional configuration, tied to the INCLUDE_CLOCK
variable and would be quite easily implementable.
Should the mitigation above not be desired, I'd recommend to just roll back the INCLUDE_CLOCK
-option. (Which affects this repository and the dashboard-repository).
Since this only affects a small edge-case for an optional setting I'd not prioritize it. I mainly aimed to document the current state, so no one trips over this option.