-
Notifications
You must be signed in to change notification settings - Fork 221
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Close Server Connection to Client - Feature request for moderating jam participant behaviour #434
Comments
I recommend to setup a private server. That solves the issue. |
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. |
That usually does not happen if you know your community well. There are several other techniques to solve the issue:
|
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. |
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. |
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. |
This seems like the client version of #413 :-) |
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. |
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). 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 |
I‘m currently coding a POC on my fork everything would be moderated by Chat commands. I must say that I am a complete C++ beginner and the code quality is probably bad.
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. |
Waiting room works now and you can "block" clients. This means that they’re audio will not be mixed into others‘ mixes. Edu mode can be enabled on my fork of jamulus by adding 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) 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!! |
Ability to remove connected clients or waiting room would be a really good addition. |
I sense a reluctance to add the feature. Is it a coding issue? Something else? |
@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 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. |
Line 693 in 719f861
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. |
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. |
I think so far we have:
|
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. |
Consider a server created for the primary use of a band, chorus, or orchestra. 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. |
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. |
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. |
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. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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.
The text was updated successfully, but these errors were encountered: