Add Docker server image

[walking-octopus]

Wolfram Engine can officially ship as a Docker image, which is preferable in many environments.

It would probably be trivial to create a Docker image for this repo that depends on Wolfram Engine, making it much easier to deploy.

[yloose]

I have recently tried to create a container, although more for personal use, feel free to take inspiration here. For my use case, deploying on a server and behind a reverse proxy, I had some problems with all the different ports and hardcoded protocols, but I guess it is more intended for desktop use with electron. Cool project nonetheless 👍

[JerryI]

I have recently tried to create a container, although more for personal use, feel free to take inspiration here. For my use case, deploying on a server and behind a reverse proxy, I had some problems with all the different ports and hardcoded protocols, but I guess it is more intended for desktop use with electron. Cool project nonetheless 👍

Awesome! Thank you, @yloose ❤️
We will test you solution and will fix bugs coming from the navigation and etc.
The idea with TLS is really inventive ;) @KirillBelovTest had many attempts to implement TLS on the level of TCP server, but faced some serious difficulties. We were actually thinking to hook up an external library for that.

Anyway we should consider to make changes to the main repo in order to make such tricks with TLS easier.

PS: You are right, most people are using it as Desktop app, which moved our attention away from the web-version. But since it is now quite frequently requested, we reconsider that.

[JerryI]

We shall include your repo to the main page (README.md).

[yloose]

That sounds great 👍 please let me know if you need any help regarding the container.

Anyway we should consider to make changes to the main repo in order to make such tricks with TLS easier.

That would be nice, I just took a quick look and something like this would probably be enough, but I need to do some more testing.

[JerryI]

That sounds great 👍 please let me know if you need any help regarding the container.

Anyway we should consider to make changes to the main repo in order to make such tricks with TLS easier.

That would be nice, I just took a quick look and something like this would probably be enough, but I need to do some more testing.

Great and simple idea :)
Merged to dev branch, I will test and if everything is fine I will push it to main branch. Also this I changed accordingly

[JerryI]

Checked. Works fine. Merged to main

[yloose]

Very nice, works great!

[yloose]

If the container is tested some more, I've looked into integrating it into to the main repo using github actions so it gets build automatically on every release or manually against any branch. Cf. my fork. That way users don't have to build the container manually and can just pull it from ghcr.io.

[JerryI]

If the container is tested some more, I've looked into integrating it into to the main repo using github actions so it gets build automatically on every release or manually against any branch. Cf. my fork. That way users don't have to build the container manually and can just pull it from ghcr.io.

I have a little experience with docker, but managed to start it using your fork :)
I believe the biggest issues for a user might be licensing. I don't know, but is there any solution to start it in the interactive mode and activate WL from cmd on the first run?

Tried this

sudo docker run -it -v WolframLicensing:/Licensing -v ~/Documents/wljs:/workspace -e PUID=2000 -e PGID=2000 -p 4000:4000 -p 4001:4001 -p 4002:4002 -p 4003:4003 --name wljs ghcr.io/yloose/wolfram-js-frontend:latest


No license file available!

[yloose]

I have used the same mathpass file the whole time that I have once generated with wolframscript -activate. When I looked into building the container earlier this year, I had some really annoying problems with the whole account stuff. I could only generate two licenses per account and couldn't reset them...

Anyways after trying now it all worked pretty good. I have updated the container and README. You can enter the credentials interactively or pass them via environment variables. This container should be up to date: ghcr.io/yloose/wolfram-js-frontend:main.

[JerryI]

Thank you. It worked for me

I see some issues with navigating. However, this is an easy fix. By the way, I don't know if this is a feature of naming, but it only worked if change for each command mentioned in README latest to main.

I believe I also need to add privilege for read/write access check within the frontend. So that a red message pop up, if a folder does not have right groupid.

[JerryI]

UPD: pushed changes to dev

[yloose]

Great! Yeah so the way it is setup is that Github automatically builds a docker image on release with the tag <repo>:<release_version> e.g. ghcr.io/yloose/wolfram-js-frontend:v1.1.0. The newest release is also tagged with <repo>:latest. That way when using latest the user always gets the latest stable release. You can however generate an image directly from a branch, in this case main, which is then tagged with the branch name e.g. <repo>:main. The changes with the authentication where only on the main branch and not in any release, thats why you needed to use main.

[yloose]

I believe I also need to add privilege for read/write access check within the frontend. So that a red message pop up, if a folder does not have right groupid.

That is a good idea, I also thought of maybe adding a way to restrict the navigation: For example a --root-dir flag, where a directory could be set which cannot be left in the UI, i.d. the user cannot navigate upwards anymore. Because in the container it does not make sense to leave to working directory. Though I don't know how hard that would be to implement, just an idea.

[JerryI]

I believe I also need to add privilege for read/write access check within the frontend. So that a red message pop up, if a folder does not have right groupid.

That is a good idea, I also thought of maybe adding a way to restrict the navigation: For example a --root-dir flag, where a directory could be set which cannot be left in the UI, i.d. the user cannot navigate upwards anymore. Because in the container it does not make sense to leave to working directory. Though I don't know how hard that would be to implement, just an idea.

I did exactly this. A button should just disappear if a user is already in a working directory provided by folder argument you used already.

[JerryI]

I suggest moving the Activation section up since this is the first step for new users. Additionally, add a small tutorial section for first-time users. For example: (probably its an overkill :D )

Tutorial

1. Install docker or podman on your machine if you do not have them already.

2. Pull the image:

   docker pull ghcr.io/yloose/wolfram-js-frontend:latest

3. Run the image:

   docker run -it -v WolframLicensing:/Licensing -v ~/Documents/wljs:/workspace -e PUID=2000 -e PGID=2000 -p 4000:4000 -p 4001:4001 -p 4002:4002 -p 4003:4003 --name wljs ghcr.io/yloose/wolfram-js-frontend:latest

4. Check the read/write permissions (group ID) for the ~/Documents/wljs folder on your local machine. Set it to ..........

5. Register at the Wolfram Engine download page. Click to download (only needed to be redirected to the right place) and then follow the Get your license instructions. Register on the next page and acquire the license (it is free). A confirmation message will be sent to your email address. Please follow the link received by email.

6. Enter your login/password information in the console after step (3).

7. Wait until the message Open your browser at http://... appears.

8. Open a web browser and go to:

   http://127.0.0.1:4000
   

   or, if you are running it on a remote server:

   http://<public-ip>:4000
   

[yloose]

I did some refactoring using your example, let me know what you think 😄 (Link). I also changed the example docker run command so the uid and gid of the user inside the container is the same as the user starting the container. This way some of the manual permission checking at step 4 should hopefully be resolved.

[JerryI]

I did some refactoring using your example, let me know what you think 😄 (Link). I also changed the example docker run command so the uid and gid of the user inside the container is the same as the user starting the container. This way some of the manual permission checking at step 4 should hopefully be resolved.

Awesome! I think it’s time to open pull request :)