Prevent accidental shutdowns from some well-intentioned process on your internal network
Secure your server from malicious intent in case they’re publicly exposed
CommandBox is a development tool so I think its reasonable to expect it to only used inside trusted, internal networks. In that scenario, I’d just set some one-time string and hardcode it. It’s not “security” per se, just a big of accident-proofing to filter out miscellaneous connections from creating false-positives.
I don’t know how likely it is that people will be running embedded CommandBox servers on a public network, and if they do I don’t know that it’s really our fault. If we’re going to try and harden the embedded server to make it secure for public access, that really sounds more comprehensive and a lot of work. I’d be tempted to simply say, “the embedded server is not secure-by-default and for internal use”. That’s basically that stuff like XAMPP does. Heck, they leave your MySQL root password blank and just tell you that it’s not for production use.
“the embedded server is not secure-by-default and for internal use” - is my thoughts on it as well. I don’t see CmdB/Runwar trying to replace a full Railo or ACF installation on a public facing machine (though I could see some people trying). So I don’t imagine it’s worth it to try and secure a simple dos vulnerability
*I’m just a dev who understands the tools and uses ‘correctly’, my opinion shouldn’t carry much weight
Keeping it in a config file might be the direction to go, in
WEB-INF/runwar.json or some such. I'd just added some stuff that would
make that pretty doable.
"the embedded server is not secure-by-default and for internal use" - is my
thoughts on it as well. I don't see CmdB/Runwar trying to replace a full
Railo or ACF installation on a public facing machine (though I could see
some people trying). So I don't imagine it's worth it to try and secure a
simple dos vulnerability
I use runwar "in real life" so it's important to me.
It can outperform a "full" install, and is great for limited resources
(VMs and such, similar to jetty-runner).
There are a lot of benefits to a bare-bones container, just as there are
a lot of benefits to containers like WildFly. So while commandbox isn't
aiming at "production level" serving capability, runwar is. Not all
hard-core-like, but more than just phoning it in. Middle'n it.
*I'm just a dev who understands the tools and uses 'correctly', my opinion
shouldn't carry much weight
You carry weight by the very fact of being a squirrel trying to get a
nut, so to speak, which is why we're all here, so be assured that your
input is quite valuable. Thanks for taking the time to share it hombre!
I just realized CommandBox could use java directly to open a socket and write to the stop socket runwar is listening on. Just throwing an option out there.
