If they could be urged that not exposing their users to random script injections or credential-sniffing should be a priority, then I would recommend said urging. Also, maybe more relevantly to a company trying to make money, Google's SEO de-emphasizes non-HTTPS sites.

Patience isn't really a factor for something like this, but I'm glad it's on the roadmap. What is the hosting situation of the forum, because if it's anything closer to the wire than a 1&1 budget hosting instance, I guarantee you it will take maybe ten minutes of work to put an ssl-terminating nginx proxy with a self-updating Let's Encrypt cert on the server's port 443 and just fix it for good without waiting for a revamp.

It would also allow you to serve this over web-standard ports rather than having 4567 as your canonical, so you'd get double benefits.

Thanks for the pointer, I had originally seen the empty project and figured it was defunct, but eventually found a link to the Issues page elsewhere and figured out what was going on.

Seriously, it's 2018 and this forum isn't served over TLS. There are free certs available everywhere and tutorials for literally any webserver you could possibly think of, and it's typically stupid easy to set it up with a free Let's Encrypt cert. There is no excuse.

Is this still where to post bugs? There evidently was an issue tracker at some point, but that Github project is empty.

Anyway, here's the bug: The server forces the listening interface (with :3001) as the hostname for all generated links, generally addressing them at whatever IP address the game server detects it is listening on (which is usually internal). This breaks lots of different ways of directing traffic to the webserver (DNS, for instance, or anything over a NAT), and should be configurable--if it is already configurable, then it should be mentioned somewhere.

This is in 7.4.4-beta