Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
My point is not that its difficult just that there are a lot of parameters and command line arguments is probably not the best way of handling this. I am thinking that maybe a second ini file with the overrides, which the hosting provider can set to unwritable by the user, may be the best option.
Posts: 116
Threads: 3
Joined: Sep 2014
Thanks: 31
Given 15 thank(s) in 11 post(s)
I believe that optional ini file with overrides is the most reasonable option.
Also, i don't think plugin sandboxing is really that important - it'd be nice to have, but your average minecraft user won't use it to mess things up on purpose.
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
I agree, and think that sandboxing is unneeded in the initial implementation, but whatever option we choose should be able to handle it.
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
I'll look into it tomorrow. The work I'm currently doing has got stalled in design issues.
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
I'm just worried about the future impact of a command line like mcserver -s=20 -p=25565 --portv4=none --portv6=none --plugin-port-whitelist=none --ip=127.0.0.1 --ipv4=none --ipv6=none --plugin-address-whitelist
Have you seen what the build calls to compiler in an MCServer build are like? That's what a call to MCServer would be like to lock it down.