You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the process of configuring the .envs files is a pain. Mostly we just copy them around. Once we accidentally included them in a public git repo. (Yikes!!) These are bad solutions.
Ideally it would be possible to create a new deploy by cloning the repo and running a script that creates the env files for us, asking just a few targeted questions (like what the domain name should be). However...
This might raise security questions.
The more someone knows about how our DB passwords are being generated, the more likely they are to figure out a way to crack them. I have no idea what the best practice is when it come to this kind of thing. In theory, if the script uses a very secure method to generate the passwords, it's probably fine, but we should be careful.
The alternative would be to have the script ask for the passwords, and encourage users to generate their own using a trusted password generator. But that's less convenient, and of course users might make a bad choice of generator, or be really lazy and enter something like 12345. (That's probably just a venial sin in testing but it's a mortal sin in production.)
Still, the script will definitely have to ask for some things (like, at a minimum, the domain name) so that alternative isn't crazy.
Also
In an ideal world, the script would give two options -- default would be interactive question answering, but you could also pass values as flags, and if you pass flags for all the questions, it's totally automated, with no interaction.
The text was updated successfully, but these errors were encountered:
Right now the process of configuring the
.envs
files is a pain. Mostly we just copy them around. Once we accidentally included them in a public git repo. (Yikes!!) These are bad solutions.Ideally it would be possible to create a new deploy by cloning the repo and running a script that creates the env files for us, asking just a few targeted questions (like what the domain name should be). However...
This might raise security questions.
The more someone knows about how our DB passwords are being generated, the more likely they are to figure out a way to crack them. I have no idea what the best practice is when it come to this kind of thing. In theory, if the script uses a very secure method to generate the passwords, it's probably fine, but we should be careful.
The alternative would be to have the script ask for the passwords, and encourage users to generate their own using a trusted password generator. But that's less convenient, and of course users might make a bad choice of generator, or be really lazy and enter something like 12345. (That's probably just a venial sin in testing but it's a mortal sin in production.)
Still, the script will definitely have to ask for some things (like, at a minimum, the domain name) so that alternative isn't crazy.
Also
In an ideal world, the script would give two options -- default would be interactive question answering, but you could also pass values as flags, and if you pass flags for all the questions, it's totally automated, with no interaction.
The text was updated successfully, but these errors were encountered: