Mixed content error if OpenEMS is behind reverse proxy with HTTPS

[helgeklein]

Description

Overview

A common method to secure access to a web-based application like the OpenEMS UI is to place it behind a reverse proxy such as Caddy. The reverse proxy may serve multiple purposes, the most important of which are: provide HTTPS transport encryption, and perform user authentication.

The issue

If placed behind such a reverse proxy, all connections must follow the HTTPS or WSS URI schemes, or a browser like Chrome issues the following type of error:

Mixed Content: The page at '<URL>' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://<URL>'. This request has been blocked; this endpoint must be available over WSS.

This is exactly what happens because the JavaScript code in the browser statically uses the ws: URI scheme instead of dynamically choosing between ws: and wss:. If I understand the code correctly, this happens in exactly one place, line 8 of backend-prod.ts.

How to fix it

This should be simple to fix by checking if the current URI scheme is HTTPS or HTTP and selection WSS or WS, respectively. This StackOverflow answer shows how it can be implemented.

Screenshots

No response

Operating System

No response

How to reproduce the Error?

Place OpenEMS behind a reverse proxy like Caddy that provides HTTPS transport encryption. In its simplest form the following is required in the Caddyfile:

pv.{$MY_DOMAIN} {
         reverse_proxy fenecon.{$MY_DOMAIN}:80
}

In the above example, {$MY_DOMAIN} is an environment variable containing the domain name of my home network. pv is the hostname under which Caddy serves the proxied site over HTTPS. fenecon is the hostname of the OpenEMS installation that is accessed via unencrypted HTTP.

[Sn0w3y]

This is not really an issue. The existing configuration fundamentally works as intended, as long as it’s clear in which context (e.g. behind an HTTPS reverse proxy) the application is running. If desired, the code can be adjusted to dynamically switch from “ws://” to “wss://”, but this is more of an optional optimization for special environments. The suggestion can certainly be submitted as a PR. In my view, the issue can therefore be closed, @sfeilmeier

[helgeklein]

I just created pull request #2937 to fix the issue.