localhost paths seem hardcoded — impossible to run the app on a remote server

[GentleHoneyLover]

Hi,

I'm running TNoodle-WCA-1.1.2.jar in a container (here's my image: link). It is basically a slight modification of the Dockerfile from your repo. When I deploy the container on localhost (my laptop) it runs just fine and generates scrambles correctly (Screenshot 1 below). However, when I run the same image on my home server (accessed via ip-address:port or through reverse-proxy), the app breaks (Screenshot 2 below). Presumably because localhost paths are hardcoded in the app.

Is that the case? Are there workarounds (like e. g. passing some arguments to java when starting the app)? Or, otherwise, can the app be updated to make all URL paths dynamic rather than static localhost?

Here's how the app starts from within the container:
java -server -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:InitialRAMFraction=2 -XX:MinRAMFraction=2 -XX:MaxRAMFraction=2 -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+UseStringDeduplication -jar tnoodle-application.jar --online

Screenshot 1 (localhost):

Screenshot 2 (server):

[GentleHoneyLover]

Would be great if somebody could help out here! Thanks!

[gregorbg]

Hey there, sorry for the delay! TNoodle was never conceived to run in remote containers, the Dockerfile we're providing is really just a "proof of concept" and not an officially supported means of development.

You are right that localhost is indeed hardcoded, at https://github.com/thewca/tnoodle/blob/master/tnoodle-ui/src/main/api/tnoodle.api.ts#L12. We do not have the capacity at the moment to come up with a smarter solution.

In other news, TNoodle will soon be retired in favor of more modern scrambling algorithms anyways. We're not ready to share all the details yet, but for most projects you can take a look at https://js.cubing.net/cubing/scramble/. Active development on TNoodle has ceased and we're driving the project forward in a "ciritcal bugfixes only" mode.