Close Server Connection to Client - Feature request for moderating jam participant behaviour

[alanhahn]

Allow the server admin to close individual client connections to stop disruptions. In other words, the jam coordinator can kick someone out of the jam for bad behaviour.

In the GUI I envision a right mouse click on the client's entry and, in addition to "What's This?", there is a "Close Connection" choice.

[corrados]

I recommend to setup a private server. That solves the issue.

[alanhahn]

It doesn't solve the issue if the location of the private server is made available, unintentionally, to those who become disruptive. Or, there is a good reason for maintaining the server as public even if it attracts bad behaviour.

[corrados]

private server is made available, unintentionally

That usually does not happen if you know your community well.

There are several other techniques to solve the issue:

• If your choir has, e.g., 12 members -> set the maximum allowed number of clients to 12 in the server. Then if all your choir members are connected, the server is full and nobody else can join.
• Set all your choir members to Solo. Then you will hear only those.
• Move the fader of the unwanted client to the bottom or activate the Mute button. Jamulus will store this setting.

[pljones]

This request has been mentioned a few times, so I thought it might be worth raising.

The problem with "set the number of clients" is that someone disruptive might get in and busy out your server. Yes, you can bounce with disconnectall (or, better, always run with disconnectonquit) but it's more disruption for everyone else.

Asking every member to mute the disruptive person doesn't stop them busying out the server.

Asking every member of a choir to solo every member of the choir every time they join the server is disruptive in itself. And if someone new joins the choir, everyone has to remember to solo them so they can hear them saying "Hello". (And still doesn't stop the server being busied out.)

A "block IP" from the server GUI would allow an admin to take direct action against a disruptive user and, in most cases, solve the problem very simply. Anyone managing to bomb a server from multiple IPs is a more dangerous level of threat than I'd suggest needs covering here.

[alanhahn]

Thanks, Peter for fleshing out what I am asking for. I did not think of the 'Block IP' option but that is better than a 'Disconnect' choice because it prevents the person from rejoining over and over again.

[pljones]

It doesn't prevent them bombing the server with traffic, unfortunately - only your firewall can do that, and even then, if you're running over a domestic connection to the server, they may well be able to bomb your IP enough other traffic can't get through. Hopefully your ISP would spot this kind of antisocial behaviour and block it for you, though.

[gilgongo]

This seems like the client version of #413 :-)

[corrados]

Asking every member of a choir to solo every member of the choir every time they join the server is disruptive in itself.

That is not needed. The Solo state is stored in the settings. So if you have set it up once, you do not have to do it again on your next rehearsal.

[Brian-McBride]

private server is made available, unintentionally

That usually does not happen if you know your community well.

I really hope that Jamulus becomes insanely popular in the educational space. What is being built here is awesome. Unfortunately, if the platform becomes popular, then there WILL be people who run bots to find private servers.

Well, let us be clear - there is no such thing as a private server if it has a public IP. At that point, it is only a secure or insecure server. Security through obfuscation is not security.

I've been advocating for a separation of concerns (UI from Engine).
Issue 472 If the server had a method to set temp access codes and then these could be provided through a URL or sent to clients or through a full OAuth server flow - how the end client gets the access code is less important that it is possible to set one on the server to enable connections.

I'm constantly thinking from an education standpoint. Ideally, for me, students log into Google Classrooms. There is a link and they click on it which then launches a custom client of Jamulus (explained in 472) that leverages the same Google Auth that the Google Classroom platform does. All this is in my wheelhouse and my day to day development. What I lack is the C++ audio library client and server skills. GIve me that engine so I can run with advanced UIs, and I'll do my best to make Jamulus the "Zoom" for school music classes

[ann0see]

I‘m currently coding a POC on my fork
on the eduTools branch.
https://github.com/ann0see/jamulus/tree/eduTools

everything would be moderated by Chat commands.

I must say that I am a complete C++ beginner and the code quality is probably bad.
There’s no working ban/block yet but you can already enable/disable chat.

The "Waiting room“ feature doesn’t work yet. It probably has to be done differently. Waiting room works now.

The Admin password verification would have to be made more secure, at least the PW should be hashed, maybe even some kind of encryption should be added.

Furthermore I don’t really think that this or a more developed version would be merged.

[ann0see]

Waiting room works now and you can "block" clients. This means that they’re audio will not be mixed into others‘ mixes.
Probably there’s a better way to do it (mute specific user for everybody and block unmute,... on Server etc.)
The code is far from finished but I‘d appreciate to have some input.

Edu mode can be enabled on my fork of jamulus by adding --edumodepassword {PW}

Commands to the server are sent via chat (/c/{PW} sets current user to admin; I currently don’t check if {PW} is a command which could be executed —> to be fixed)
You can block clients by sending /c/moveIDAway {id} and unblock them with /c/enableID {id}

The code is quite untested at the moment and I’ll be unavailable for some days. Nevertheless feel free to test/have a look at it. But it’s not production ready!!

[sebukoleth]

Ability to remove connected clients or waiting room would be a really good addition.

[JerryWithaJ]

I sense a reluctance to add the feature. Is it a coding issue? Something else?
I'd find it very useful to be able to disconnect a client.
I run some what I'll call semi-public sessions, that is, signup is required to get the address of the server, but participants are required to meet some requirements (for example, we should already have played together in some contexts, or only certain instruments are allowed). It would be such a boon to be able to simply disconnect someone who didn't belong there. No fuss, no muss.
Thanks for considering it.

[gilgongo]

@JerryWithaJ I think part of the reason is that the nature of the UDP connection between the client and server make server-side disconnection of clients difficult.

There is however the --discononquit server option, which will successfully disconnect all clients from the server when the server quits. So I don't know if some modification of that might be possible for a running server.

Meanwhile, and depending on the use case, you can of course simply drop the route on any connected IP address if you needed to ensure that address can't connect.

[hoffie]

jamulus/src/server.cpp

Line 693 in 719f861

if ( bDisconnectAllClientsOnQuit )

There is however the --discononquit server option, which will successfully disconnect all clients from the server when the server quits. So I don't know if some modification of that might be possible for a running server.

Yes, this should be possible as this is just a loop over the relevant protocol message. However, I would rather treat this as informational or as a suggestion for the client. A malicious Jamulus client could just ignore this protocol message. A less technical but still malicious person can just keep reconnecting.

So, the request here rather sounds like access control, i.e. either having a password-protected server (#299) or having a way to permanently block a user. As users do not have any permanent unique IDs or something, the best thing is probably the IP address, so iptables/nullrouting is most likely the best available tool in this case.

[gene96817]

It is one of several scenarios that can be implemented with access control. I recommend we discuss all the use cases that can benefit from access control. We should not be creating an access control inside of Jamulus, instead, there should be a mechanism for using existing access control methods. OpenPAM is a good starting point.

[gilgongo]

@gene96817

I think so far we have:

1. Server owner wishes to remove client(s) from their server
2. Server owner wishes to run a public or private server which allows only authenticated users (I think @ann0see has done some work on this)

[ann0see]

Yes. I did something (see my eduTools branch) but it's far from secure or user friendly. If anybody wants to take the code, just feel free to use it.

[gene96817]

Consider a server created for the primary use of a band, chorus, or orchestra.
2 above allows for private rehearsals and would cause the server to be unused all other times.
3- generalize #2 to server owner wishes to have a private session to only authenticated users. This would allow the server to be used when there are no private rehearsals.
4- Add allowing (some) authenticated users to create a private session. (not just the server owner). This would allow the ensemble members to have private rehearsal times without requiring the server owner to administer to every private session.
5- This could then be generalized to allow authenticated users to schedule a private session.

If the authentication module (database) is external to Jamulus, it would be possible for some people to add and remove people to the authentication and give temporary authenticated user status.

Note that authentication introduces the need to handle lost passwords and password resets. Let the server owner choose their authentication module/service. We can select a default module. Just don't write another authentication module.

[gilgongo]

I don't think we have any shortage of use cases then :-)

I'll defer to the more knowledgeable on this, but implementing an authentication layer of some kind for Jamulus (particularly in the case of 4 above!) sounds like a very large architectural change.

[gene96817]

If we use an external authentication module, then Jamulus needs only to pass the userid and credentials to the external module for a yes or no for connection.

[gilgongo]

Hi all - until we have agreed an actionable spec for the work necessary to be done for the backlog on this, I'm moving it to a discussion if that's OK.