[Feature] Different user permissions

bannmann commented 10 months ago

Similar to online conferencing software like Zoom, Google Meet or MS Teams, sshx should distinguish user permission levels. This would greatly increase its usefulness in teaching settings (particularly with larger audiences of 10+ people), or in video conferences with attendees of mixed seniority levels.

Here is how I imagine this could work:

The first user to connect to the session becomes the host.
A session starts in "default" mode where every user has "full access" level. When the host activates "limited" mode, sshx moves every other user to "guest access", but still shows their mouse cursors and lets them enter chat messages. Users joining afterwards will also be on "guest access".
- This way, the host can present stuff and others can point at things or ask questions, but nobody can goof around and disturb the presentation. Also, in case it's a production system, the host does not have to watch out for people doing dangerous stuff.
While in "limited" mode, the host may change each user from "guest access" to "full access" and back at any time.
- This is useful if someone from the audience is supposed to take over for a while.
The host can leave "limited" mode at any time.
Additionally, there could be a feature allowing hosts to designate other users as co-hosts.

jankatins commented 10 months ago

Another ideas would be a --read-only share and the server on my host printing (and asking) if a command should be run

webnerdnick commented 9 months ago

I think this feature request should be at the top of the list. I think an easy way to quickly implement this at a bare minimum would be a read/write mode that can simply be toggled in the UI by the persons name in the list that appears in the top left. This toggling should only be able to be done by the primary host. An alternative to toggling in the UI may be to list joined participants in the CLI output on the host, and allow selections there for who can read/write.

luochen1990 commented 2 months ago

Another related feature is: the host can confirm it before the command output shared to everyone.

The scenario is if the host check logs via journalctl and there is a pwd or token there, you will not hope it displayed to guests

lukehsiao commented 2 weeks ago

sshx is the best terminal sharing solution I've tried so far. However, I really just need a read-only mode. That is, my common use case is just sharing my terminal to many people, and I do not want them to be able to click/input or open other terminals (I often start a session, then open a tmux/zellij session and work in my own terminal directly, not in the web interface, so I do not want to have to check that people are not doing other things in other terminals in the web UI).

If this type of read-only broadcast is something fairly straightforward to implement (vs the more complex user permissions) I would be happy to help contribute.

ekzhang commented 2 weeks ago

Okay makes sense! The tricky thing is that in sshx, only web clients may exist -- so read-only mode would require an additional secret / different URLs for the reader and writer.

It would probably require an API change as well as a frontend change. We could enable this when --read-only flag is passed in perhaps, or --read-only-mode or --enable-readers idk what the right flag name is right now

I'll take contributions for it!

lukehsiao commented 2 weeks ago

Okay makes sense! The tricky thing is that in sshx, only web clients may exist -- so read-only mode would require an additional secret / different URLs for the reader and writer.

It would probably require an API change as well as a frontend change. We could enable this when --read-only flag is passed in perhaps, or --read-only-mode or --enable-readers idk what the right flag name is right now

I'll take contributions for it!

I see, a little more involved then. Could you provide any pointers on grokking where those changes might need to happen?

ekzhang commented 2 weeks ago

https://github.com/ekzhang/sshx/blob/36beaf664afc58b0ca349f06ee0fe820a09ad166/crates/sshx-core/proto/sshx.proto#L7-L16

This is the gRPC service definition used by the client. OpenRequest should take a new bool field for enabling readonly mode. Protobuf will default this to false for older clients that don't have the field. OpenResponse should return some kind of additional password needed to get write access to the terminal, which can be stored on the Metadata of the session (this needs to be persisted in snapshots also).

https://github.com/ekzhang/sshx/blob/36beaf664afc58b0ca349f06ee0fe820a09ad166/crates/sshx-server/src/session.rs#L28-L36

On the web client, the WebSocket connection needs a way to authenticate with the write-access password. It's possible you just add that to Authenticate as an optional bytes field, since the web protocol doesn't need to be backwards-compatible like gRPC does.

https://github.com/ekzhang/sshx/blob/36beaf664afc58b0ca349f06ee0fe820a09ad166/crates/sshx-server/src/web/protocol.rs#L70-L77

Then the handler here can enable write-only mode based on whether that's set on the terminal and on checking the write-mode password via constant time comparison here

https://github.com/ekzhang/sshx/blob/36beaf664afc58b0ca349f06ee0fe820a09ad166/crates/sshx-server/src/web/socket.rs#L98-L104

And on the frontend, in read-only mode we can perhaps show a little read-only indicator badge here, while also disabling edits on the XTerm terminals.

Additionally the CLI should print out URLs for both the read-only and writable modes.

ekzhang / sshx

[Feature] Different user permissions #72