Hey all,
Just wondering what’s the Slim way of managing settings local vs remote. id: db credentials, etc. I like most (i think) develop everything locally and then push code to remote server (occasionally ftp but ideally with version control )
In the past I used to grab the url and sniff out the environment that way. So I would have a settings file with 2 sets of credentials. What do you slim guys & gals do?
I have a settings.php file that is not under version control. The values vary by environment (production, staging, development, local, etc). I manually edit them as needed, but the only values in each one are the ones valid for that environment.
Yes, I suppose that’s a good way to do it.
I wrote up my thoughts here: https://akrabat.com/configuration-in-slim-framework/
Interesting Rob, I had never heard of dotenv https://packagist.org/packages/vlucas/phpdotenv before but after reading through your post and about dotenv it does make sense. Maybe I’m wrong but I think having the configs as a hidden file ( .env) is safer?
A .env file is not safer at all.
.env is interesting as in production/staging you use proper environment variables (or have them given to you if it’s a cloud provider) and the .env file for local dev.
There is also a case for not using environment variables to store configuration, particularly when it comes to anything sensitive. See How to keep a secret for that point of view. Their point hinges around:
Environment variables in PHP are possibly exposed to public
(Emphasis mine.) This can be avoided, but can also become a simple mistake with big consequences.
So… does .env makes it easier to track the environmental configs rather than monkey around with fragmented settings all over the place… i.e.: http conf vhosts htaccess php.ini etc. does this .env allow you to have all that stuff in there instead? Otherwise I’m not quite sure what’s the point.
Others frameworks uses “Environment Variables” and I think that is a good solution.
You have a similar problem like this
An okay discussion that left my head spinning although they seem to be talking more about global settings like siteName, etc… I was wondering about config stuff like db passwords, etc.
I honestly can’t understand why putting settings in code (i.e.: settings.php) is any more dangerous then using an .env file (some seem to believe so ) If your site gets hacked, it’s hacked and the hackers have access to all your files regardless.
That isn’t necessarily true. There are numerous types of vulnerabilities which have different levels of exposure. But I wholeheartedly agree that if your site is compromised you should treat the situation as though everything was accessed.
I personally dislike using environment variables, partially because I use PAAS type hosting which could increase the risk of exposure.
But for the type of settings you are talking about I put them in a settings.php file which returns an array. Should I make any changes that require a change to that settings file I manually update each environment since it is outside of version control.
Seems simple, yet reasonable (as per usual with your advice ) Thanks for taking the time to explain. I always look forward to our discussions.