Alright, I applied your changes Don, they're in runwar 2.2.1 if you want
to give it a spin and check.
I also updated CommandBox on it as well.
Cool, so just check the latest CommandBox Don, if you're up to it.
...
over ssl probably, etc.. Thanks for your contribution, and do you have
any input on the password deal? I'm open so suggestions.
I don’t know if am very concerned with it, but maybe setting a default password is good. And maybe a way to change it on a per server level is also good.
It certainly needs to be protected somehow-- random shutting down of
servers, development or production, is never fun.
I think maybe only allowing binding the stop listener to external
interfaces if a password has been set, otherwise having it use localhost
might work.
Gonna have to think about it a bit. Don't really want to pass passwords
around either.
With that in mind, I have a question, (As I have not had time to digest runwar just yet). Does undertow support SSL? This is a key component sometimes for local development.
Sure undertow will do SSL. I haven't added that to runwar though.
Shouldn't be too hard to add, he says famously.
I assume it’s just a matter of find the matching programmatic configuration. Denny, do you have any links that documents the API run war uses to bootsrap the servlets and listeners? My Googling has always turned up nothing more than flimsy marketing pages on the JBoss site extolling the high-level virtues of Undertow (and Wildfly) but it seems a lot harder to actually unearth their Java docs, or API docs for programmatic configuration like we’re doing.
I was looking at the undertow doc http://undertow.io/documentation/servlet/security.html
Maybe use the Authorization header with a random hash, then that could be passed around internally to runwar (and by extension saved to commandboxs server info json) instead of a password. But I don’t see how to apply this to Only the stop socket
Denny, can you explain how the stop socket works? You said just sending a packet to that port on that interface is enough to trigger the shutdown?
Is this a J2EE or servlet thing, or something of your own design? What OSI network level is this happening at? Is it literally just ethernet frames in the form of a TCP packet, or is an HTTP request being sent to this port?
Also, when you say password, are you thinking of some plain text string that’s streamed to that port? Would the user need to type it, or would we just randomly generate something and store it in servers.json for that server and pass it to prove we’re friendly? Where would we write the code to see what was passed to the stop socket?
I’m just trying to understand how it works and what pieces we have control over.
It appears you just open a socket connection to that port (like with telnet) and send that text followed by a carriage return. I’m unclear on if that’s just a Tomcat implementation, or the general spec that all servlet containers follow.
If that’s true, then I don’t see how a portscan would shut down your server. If undertow works the same way, just generate a random shutdown string and store it.
WildFly == JBoss AS, which has freaking oodles more cool stuff than
stock Undertow comes with. So you'll see lots of stuff for WF, vs.
Undertow itself, which is intentionally bare-bones.
As for the Undertow API, it's pretty straightforward. I haven't needed
more than the tests and source code. The docs on the site cover the
basics, FWIW.
I'm obviously not a visual learner though-- I strive to write code that
is self-documenting.
Start at the tests though, they have good coverage, and examples too.
It appears you just open a socket connection to that port (like with
telnet) and send that text followed by a carriage return. I'm
unclear on if that's just a Tomcat implementation, or the general
spec that all servlet containers follow.
They do different things to achieve the same ends. Some have listeners,
some have watchdogs, but conceptually they do the same thing.
And yep, ours just listens for a carriage return.
If that's true, then I don't see how a portscan would shut down your
server. If undertow works the same way, just generate a random
shutdown string and store it.
Generally, if they find an open port they immediately try to do stuff
with it, and a carriage return isn't exactly unique.
Generating a random "password" if one wasn't specified wouldn't work
because the user wouldn't know what it was, right?
Authorization headers assign that the stop signal is coming across HTTP, but it’s not right? It’s just a TCP connection that streams a string of letters from what I’ve seen. From what I’ve seen, stop connections appear to operate at a lower network level that HTTP.
> Generally, if they find an open port they immediately try to do stuff > with it, and a carriage return isn’t exactly unique.
Well, there’s a difference between saying “a portscan will shutdown the server” and saying a person with malicious intent "can easily guess how to shut down the server’
Is the carriage return just how Undertow works, or is there Java code somewhere that you wrote that is the listener?
> Generating a random “password” if one wasn’t specified wouldn’t work > because the user wouldn’t know what it was, right?
I assumed this wouldn’t anything we’d bother the user with. The “password” would simply be generated and used behind the scenes.
How were you thinking of storing it?
In servers.json where we store the shutdown port, etc.
Actually, it may need to involve CommandBox so the server status in
servers.json can be kept up to date. This is issue in that ticket I linked
to earlier where bypassing CommandBox to shut down a server is already
causing issues.
You’re right Brad. To include a stop auth code and travel through commandboxs execute() command, it would need to be stored somewhere (like the CmdB server json).
I was hoping for a secure solution without having to completely diverge the 2 projects with this single feature. Oh, or maybe just default the stopAuth to be \r\n.
Generally, if they find an open port they immediately try to do
stuff with it, and a carriage return isn't exactly unique.
Well, there's a difference between saying "a portscan will shutdown
the server" and saying a person with malicious intent "can easily
guess how to shut down the server' Is the carriage return just how
Undertow works, or is there Java code somewhere that you wrote that
is the listener?
While you can do a port scan that only checks listening ports, vs.
sending any data or trying to figure out what is running on those ports,
the automated tools aren't in general very, um, restrained, and will
indeed try to determine the services running on the open ports. I
should have been more specific, but it happens literally all the time--
just take a gander at any server logs.
The listener just reads a line (waits for a CR), basically:
Generating a random "password" if one wasn't specified wouldn't
work because the user wouldn't know what it was, right?
I assumed this wouldn't anything we'd bother the user with. The
"password" would simply be generated and used behind the scenes.
It has to get passed back in somehow, so it has to go out somehow.
It could be like the PID, which you only know /after/ you start the
program-- we just change the output to be "to stop the server, use blah
blah -stop -stoppassword gennedPass" or some such.
I dunno... we'll never think up all the stuff that other people have
already tackled (or I don't want to try :]), so I'll look around and see
what issues other folks have run into trying to do the same thing, and
get a lay of the terrain as it were.