Want to try the new Zellij Web Client and provide feedback?

[imsnif]

In the upcoming release, Zellij will include a web client. Meaning we will be able to share existing sessions in the browser as well as create new ones.

Personally, I have been daily driving the browser client as my main terminal and find it very convenient and much nicer than using a dedicated terminal application.

I'm posting here because I'm seeking user feedback about this feature's UX. If you'd like to try it out and write your impressions here, that will be very helpful. I'm looking for usage feedback specifically: what you like and don't like about the way this feature behaves, is it easy/difficult to use, what you'd like to add, are you having trouble running it, etc. So let's please keep things on topic here.

How does it work?

Zellij will come with a web server (axum) built-in. The web server will be off by default and can be started in order to serve sessions locally in the browser.

Once the web server is running, you can navigate to http://127.0.0.1:8082 in order to get the welcome-screen, from which you can start new sessions, attach to existing ones or resurrect exited ones.

Each session has a dedicated URL, eg. https://127.0.0.1:8082/grandiose-tomato - navigating to this URL will attach to the session if it exists, resurrect it if it exited and has exited or create it. This means that one can bookmark certain sessions to open and always land in the same place, regardless of whether they're running or not.

Sessions started from the terminal must be explicitly shared to be available on the browser.

Note: I recommend using the non-colliding keybinding preset so as to avoid key conflicts with the browser

How to install the preview version and run the web server

Since this feature is not released yet, one will need to compile a test branch of Zellij to use it:

1. Check out the web-client-preview branch of this repository
2. Run cargo x install /path/to/new/executable
3. Run /path/to/new/executable

You may need to install supporting libraries such as openssl-dev to compile Zellij. More info can be found in CONTRIBUTING.md.

To run the web server, you can use the new share plugin which is bound to Ctrl o + s or to Ctrl g + o + s. There you will be able to:

1. Start/Stop the web server
2. Share/Unshare the current session

You can also use the command line:
zellij web - start the server
zellij web -d - start the server in daemon mode
zellij web --stop - to stop the web server

Security

Zellij will only bind to localhost (127.0.0.1) so that only users on the same machine can connect to it. If you wish to open it up to other clients on your network (for example in order to be able to attach to a session from your phone), you will need to include an SSL certificate (see below).

In addition, to connect to the web server, you're going to need an authentication token. These can be generated and revoked through the share plugin (see above) or through the CLI with zellij web --create-token. Tokens are hashed in a local SQLite database, so they can only be displayed once upon creation.

Including an SSL certificate

The easiest way to include an SSL certificate is to use mkcert: https://github.com/FiloSottile/mkcert
Once you have generated a certificate and private key, include them in the Zellij configuration:

web_server_cert "/path/to/my/certs/localhost+3.pem"
web_server_key "/path/to/my/certs/localhost+3-key.pem"

How to configure

In the Zellij configuration file:

// whether to start the web server on Zellij startup (defaults to false)
web_server true

// the IP to listen on (defaults to 127.0.0.1, will not listen on other interfaces unless an SSL certificate it properly configured)
web_server_ip "0.0.0.0"
// The web server port to listen on (defaults to 8082)
web_server_port 443

web_client {
  cursor_blink false
  cursor_style "block"
  cursor_inactive_style "outline"
  font "monospace" // can be any font installed on your machine and accessible to the browser
  theme {
    background 100 20 30
    foreground 50 50 50
    // ...
  }
}

Looking forward to reading your usage feedback!

[DawidPietrykowski]

I think a lot of people using Zellij use reverse proxies such as Nginx or Caddy to expose hosted services. In such a setup the HTTPS connection is terminated at the proxy and the services just expose HTTP. This has the benefit of easier configuration and arguably more security as the HTTPS implementation in a reverse proxy is more tested.

To run the Zellij web server in such a case you could create a self-signed certificate for use on the local network but I think it's a hassle to maintain alongside something that's automatic.

You can also bind on 127.0.0.1 but that is a problem if you're running the proxy in a Docker container as it's on a different network and running it in network: host is not a good solution.

I do believe that it should be disallowed by default, but user should be able to allow it in config as part of enforce_https_for_localhost false. The focus should be on making sure that it's not possible to do anything on an exposed instance without the security token and mechanisms such as authorization timeouts for retries from the same IP.

Other than that, an absolutely AMAZING feature, thanks for putting in the work. I'm already using it myself (although with a patch that disables the 127.0.0.1 verification) and it's working well. Didn't encounter any noticeable issues yet.

[imsnif]

Glad you like the feature!

Regarding HTTPS: I very much understand where you're coming from. Certainly, the natural place for https termination is something like nginx. It's a dedicated solution and when setting up anything even semi-permanent that's what one should do. Enforcing https on non-public interfaces will not make this impossible, but will indeed make it a little bit more of a hassle by adding one more moving part (the internal HTTPS certificate) that you'd need to manage.

As an application developer however, I need to consider all the non-permanent solutions users will cook up as well. All the "I just need to expose this for a second so I can troubleshoot this prod issue" moments. Since we're talking about exposing one's STDIN/STDOUT to the network, doing so without https would represent a massive security breach as one could use ARP spoofing or even potentially just sniff packets on a wifi interface with monitor mode to find such things as your root password. Thus, enforcing https in such occasions to make this nigh impossible is a must, even if only to make sysadmins more confident to let their users install Zellij on their servers.

What are you using the feature for? Remote access? Locally? Daily driving? Development? Are you accessing sessions through URLs? Any special tricks you've found or thought about regarding the session URL scheme?

[DawidPietrykowski]

I understand your point. I agree that in terms of security it's better to stay on the safer side, especially if we're talking about the equivalent of an ssh session.

I personally run it on my server. Locally I run it in a dedicated terminal to not have to worry about the browser keybinds, token management and for speed reasons. But on the server this let's me access the (crucially persistent) session from any device without exchanging ssh keys. It's not something I've been running for a long time (since it just came out) but I think it will serve this use case well. I manage access with Authelia, so I have to authorize myself with a hardware key to connect. Tokens are persistent (if I understand correctly) so I will probably just store one in my Bitwarden vault and type it once when needed. This will be useful for connecting from an office for example.

The URL scheme is nice as I can have a bookmark for my persistent session which always has the same name.

I did start running into an issue though. I think it may be the recent changes as it started happening after a rebase (although from the diffs I think this logic shouldn't be affected) but I get Unauthorized or revoked login token. every time. For existing and newly created tokens. It's possible that it may just be something wrong in my setup but I didn't have time yet to debug it more extensively.

Nonetheless, very cool to see new features like this, thanks.

[imsnif]

Thanks for the detailed feedback, this was very helpful!

You can manage tokens through the share plugin or from the CLI with zellij web --list-tokens. If you are not running with --release, it could be that the tests are erasing the token DB (there is a separate DB for the tests which we distinguish by debug symbols).

Otherwise, if it's not this and you end up finding the issue I'd very much appreciate a report.

[DawidPietrykowski]

Sure, I'll try to reproduce it from the main branch on a different machine and create an issue report if the problem persists.

[DawidPietrykowski]

Managed to fix the issue, created a PR

[colemickens]

I'm running this through nginx, which is providing SSL (and this entire host is only accessible from tailscale anyway). It just works using proxy_pass to 127.0.0.1 as you might hope. (cc @DawidPietrykowski)

Observations so far:

1. (firefox) The viewport is scrunched and otherwise mangled
2. (firefox) It takes quite a while to initialize correctly
3. It triggers "Error in plugin" in the bottom bar in the main zellij window I have open
4. It isn't using my default layout?
5. Given that its not using my default layout, I can't... do any Ctrl+t / tab operations. (I wonder if the defaults will ever change 😉 )

[imsnif]

Thanks for giving this a try and for the reports! I am not reproducing most of these issues (see below), but I would love it if you help me troubleshoot these (here or in any other way that is convenient for you) because if you hit them, others surely will too.

1. Not reproducing (I'm also on firefox) - I know you mentioned this went away when you reset the zoom to 100% (I tried playing with the zoom and couldn't reproduce either)... do you maybe have some way to consistently reproduce this with? Maybe restarting the server, starting a new session, attaching to an existing session, maybe it's a font issue...?
2. Also not reproducing... What do you see when this happens?
3. Also not reproducing... Is this a custom plugin? Could it be that you are attaching to a session started from a different compiled branch of 0.43.0? Maybe you were running from main before, had a session still running and then attached to it from the web-client-preview branch? Differences between plugins in the same Zellij version can cause chaos, and I changed quite a bit in plugins in the web-client-preview branch.
4. Good catch!! I'm reproducing this and will fix.
5. I hear you! I'm using it with the non-colliding keybinding preset and it solves all these problems for me. I'm toying with making this preset the default, but I don't want to rock the boat too much atm with all the other unreleased changes.

[colemickens]

Er, the Firefox issues seem to have gone away when I reset the page zoom to 100%.

[avinal]

Nice work ❤️

It was quite an effort to compile on Fedora. 🥵 Finally I got it working; it worked fine until I changed the font. I am using Helix. In the URL bar you can see the font I am using, and I would assume it is available to Firefox. Without font settings, it works fine with a default font. On chrome the font setting worked fine.

Other than this most things worked; here are a few that didn't:

• I wasn't able to select an opening directory from the welcome page.
• Did not show me my already active sessions. (should I launch the server from some specific directory?)
• It also did not let me use any of my predefined layouts.

➜  avinal zellij action new-tab -c blowfish -l hx-compact
Failed to load layout: IoError: The layout was not found, File: hx-compact
➜  avinal zellij action new-tab -c blowfish -l ~/.config/zellij/layouts/compact-hx.kdl
^C
➜  avinal zellij action new-tab -c blowfish -l ide-layout
^C

For some layouts, which normally work, it just got stuck (like ide-layout above), and I had to use Ctrl-C to exit.

[avinal]

One tiny update: once I changed the default font on Firefox to the same font, it worked fine. So I am guessing it is a firefox issue.

[imsnif]

I wasn't able to select an opening directory from the welcome page.

Good find!! I'm reproducing and will take a look.

Did not show me my already active sessions. (should I launch the server from some specific directory?)

Sessions started from the terminal must be explicitly shared to be accessible through the web (with the share plugin, by default ctrl o + s). I'll consider making this visible in the UI somehow (eg. showing them as grayed out).

It also did not let me use any of my predefined layouts.

I think this is already fixed in main. I'm guessing your layouts were in a custom layout_folder?

Also, pinging @tlinford for the font issue - maybe he has an idea?

[tlinford]

Not really sure about the font, I would guess it's a name mismatch. When the configured font is not found it uses the browser default.

[Rekkice]

is there currently a way to include a web font in the web client's HTML? in case the font isn't installed. i'd like to access it through my android tablet's browser, and installing a font there isn't possible