Hi Denny, I’m not a Lucee dev, but I am the person who put in the ticket to make this change:
https://luceeserver.atlassian.net/browse/LDEV-926
I will add, they didn’t quite do it like I requested. I suggested they follow the pattern Jenkins uses whereby you don’t need to modify the file system, but you do need to copy a random string written to a file to prove you own the server.
The TL;DR; for CommandBox users is you can easily never see this screen by using a combination of CFConfig, DotEnv and a global .env
file that has something like
cfconfig_adminPassword=mydefaultpass
this creates a barrier for some of the devs who (still) lack a full understanding of where Lucee servers reside under CommandBox.
Security and convenience are always on a continuum. To get more of one you give up some of the other. You can see in the ticket comments above that the feature originally told the user the full folder path on the file system to go to, but it was later reduced to not be the full path. In general, you can always find the root of a CommandBox server with
server info property=serverHomeDirectory
Why has Lucee taken this step and introduced this barrier to entry?
Because the default behavior was just horrible. And I mean that. Made me sick how horrible it was. Lucee was very lucky it was never exploited en masse.
How many other engines (of any language) force a file system change to set a password?
Technically all of them. You’d have to edit the password.properties file to change the Adobe password. The only difference is the Adobe installer forces you to set a password and the Adobe war file (and CommandBox CFEngine) come with a default password, which is only one step better, but still pretty insecure.
I am of the opinion that it is not the job of the engine to enforce setting the password for the server admin.
I would disagree there. It is the job of the server to be as secure by default as possible. The old behavior was a non-starter. You can see it took 4 years for it to get fixed and that was far too long. having an exposed admin on a server you just installed is simply not an option in today’s day and age. I don’t care for the workflow of the ticket, but then again I just use the CommandBox env vars or CFConfig.json to set my default password.
this is probably the least user friendly way to accomplish it.
I’m sure they would welcome suggestions to improve it. But at the end of the day, the only way you can prove someone owns a server is to ensure they have access to the file system.
If devs and/or devops are too lazy to set a password for their admins when setting up the engine, then frankly they deserve to be hacked imho.
Nope, we can’t get away with saying that. Look how that turned out for Adobe. It took them years of saying “it’s your job to lock down cfide to not get hacked” before they realized the crap would always flow back to them every time a CF server had a high profile hack, even if it was “their fault” for not locking something down manually. Secure by default is the only way.
This just seems like a cannonball approach to solving the issue, which again shouldn’t be the responsibility of the engine, but of the individuals deploying it.
See above.
Can someone from the dev team please explain why such a heavy handed approach was taken here?
Again, please provide a better way if you have one. But the fact is web-based admins are a pain and a primary point of getting hacked. Just leaving them open isn’t an option.