I see the CasparCG client allows you to supply a username and password, is this implemented?
Where is this configured in the server config and what are the commands for passing it to the server via ACMP?
Thanks in advance
There is a functionality implemented, that allows a exclusive access to a channel. That is done via the LOCK command.
So there isn’t any login as such which is required before issuing any commands?
No. The LOCK command is made for situations were multiple operators control a single multichannel server (or multiple servers in the same network). To prevent one messing in the channel of the other, they can lock their channels.
Can the kill and restart commands be issued remotely?
I don’t understand. The communication beween the client and the server is always done via networl (TCP/IP) so, yes in that sense anything can be done “remotely”. But understand remotely not as beeing over the internet, but over the local network.
In theory one could make a Caspar server be controllable via the internet, but that is normally not of much use.
By remotely I meant not via the console.
I’ve been using CasparCG for some projects now just looking how the secure ACMP.
Surly being able to issue commands that affect the server like Kill which don’t have to be done behind some form of authentication is a security risk.
The idea behind CasparCG is, that it’s operated by a client programm and not via keying in AMCP commands into the console. The client can simply not offer a KILL to be sent. The official client is made to support everything, but a custom one can work differently. And by the way: An operator should know what he does, at least a bit 
We have our own custom clients which issue the commands via ACMP and interact with HTML templates over Websockets. The operator can not use this client to kill the server nor would I ever add that option.
If ACMP doesn’t support authentication this means anyone on that network can write there own client and issue commands like kill to the server, in my option this is a security risk.
You can see from the server log who issued the KILL command and simply fire the guy. 
Well yes but I would prefer to avoid before rather than after.
I’ve submitted a feature request, I would look at it myself but I’m not an expert in C#.
Seriously, you are right. What about isolating the network, that the Casprs reside from the “rest of the pack”? Via different subnets etc. So you would reduce the risk of some evil guy shooting in your broadcast.
AFAIK the LOCK command does it’s work based on the IP address of the client that issues the LOCK. So if your client program simply lock it’s channel you are safe also.
And by the way: The server is programmed in C++ not C#. That makes it even harder for people like we are to alter the code 
Seems Jesper thinks there might be something already present, not sure if his referring to LOCK.
Sorry, didn’t see this thread before I answered. Yes, I was thinking about LOCK. Seems to be limited to channel commands only?
One solution @grahamspr could be to use different ports (you can add multiple AMCP-ports to config) and filter access to a given port pr. client in your router (NAT).
Didn’t realise I was able to add extra ports to the config, but that would likely solve it.
Do you just repeat that part of the config with a different port?
1 Like
Yes, that’s correct.
1 Like
The conversation is being continued at github