Env Var Tricks & on Production

There is a problem with escaping $ in fastcgi_params in fact you can not set variable to a value that contains $ using the nginx config. This renders is quite useless because many generated passwords have $'s in them. How to overcome this?

Hey Venimus,

Good question! Well, it's good to not use the $ chat in your password anyway, you van always change your generated password and remove all $ chars or replace them with another special char. Otherwise, nothing much you can do here, though there's a workaround for it - use some variable defined with module which doesn't support variable interpolation, e.g. you may do so with geo:

geo $dollar {
    default "$";
}

And then use the variable instead.

The source is: https://forum.nginx.org/read.php?2,218536,218559

Unfortunately, this workaround won't work in your case anyway I think. So, just don't use $ chars.

Cheers!

Well, it is not only passwords (I just gave it as an example). For instance I wanted to store a regular expression which is passed from the deployment server and which is not under my control, so I can not simply avoid $ in such cases

Hey Venimus,

So, does that trick with non-interpolated variable I shown in my previous comment works for you? Otherwise, nothing much we can do here. You can try to ask your question on StackOverflow, probably someone has a similar problem and solved it in some way.

Cheers!

Whats the best possible option to store env variables on a apache web server, if you don't have access to the vhost config file? To still use the dotenv bundle with the .env file or to write it inside the .htaccess file inside /public? (On shared webhosting you can't access the vhost file)

Hey Mike,

It's totally OK to use Dotenv Component on production if you don't have access to the vhost config files on your hosting. I don't think it would be better to store them in .htaccess, at least because doing it in .env files are more convenient than in .htaccess. Also, it might depend on if you're able to set env vars in .htaccess or no, probably this feature might be disabled as well. So, as far as your .env files are secure and nobody can get access to them via web - it's totally OK to use them instead for storing your env vars, i.e. it's the same way as it was before with well-known parameters.yaml files.

Cheers!

Hello, I'm in the same situation as Mike, so, sorry to bother you with a really naïve question...But how can I be sure that nobody can get access to my .env file ? What can I do to be certain ? Some htaccess magic ? Could you give me an example ? I'm about to put my very first S4 app online, I spent a lot of time securing it (thanks to your awesome site), I would be quite disappointed if my .env file was easily readable. While researching about that matter on the web I found that resource which stressed me out : https://medium.com/@marcelp...
Thanks for your help.

Hey Jean-tilapin!

It's all good - security is important! In short, you have nothing to worry about. In both Symfony and Laravel (to continue from what that article says), your .env file is NOT in your public/ directory and so it is NOT accessible on the web. It's just that simple. Only things in public/ can be read by the outside world. The fact that there are some sites out there (as proven by his Google search) that DO expose their .env file is actually pretty impressive: it means they (for some reason) decided to change the default structure of their Symfony or Laravel app so that the "document root" was the root of their project, instead of public/. They probably did that because they're on shared hosting and didn't know a better way to do it.

So, as long as you're using the default directory structure, you're good, because your web server is pointing at your public/ directory, and so only things there are accessible.

Cheers!

I'm having a problem with deployment to an Ubuntu server running Apache.
I want to define the environment variables in the Apache vhost configuration and that works for the web site.
Unfortunately, it does not work for console commands since the console component has no way to get the values from Apache.
I don't really want to also put them in a .env.prod file because that breaks the DRY principle (an knowing me it will certainly break at some point).

So, what is the "proper" solution?

Thanks

Hey David P.

Nice job getting the environment variables into the vhost config. But... in my opinion (and most of the core Symfony team I believe agrees with me), you should not use real environment variables at all and should instead create a .env.local file when you deploy to production (you could create a .env.prod file, but then it would be committed to your repository).

Basically, env vars make *incredible* things possible in certain environments. They make using Docker way easier and most PAAS (like Symfony Cloud or Heroku) leverage env vars - it is *the* way to set config and they make it *super* easy. But in more traditional setups, like a server you maintain (we still have "normal" servers too), setting env vars is a pain for the exact reason you highlighted. So... don't. There is zero disadvantage to reading the .env.local file vs setting env vars. Do it, and simplify :).

Let me know if this helps!

Cheers!

On dev machine, if you don't want to setup environment variables (with fastcgi_params) you can use this list to override the .env template file:

0) symfony/dotenv package install (composer require symfony/dotenv)

1) .env file with some "template" data (database_url, app_env, so on..)

2) .env DO NOT contain any sensitive data (password, hash, so on)

3) create a copy of .env file: named ".env.local" or similar

4) add the new file name to .gitignore

5) insert/replace the code below to use the newly created .env.local file into your public/index.php file (this is one of the "missing / incomplete / not clear" part of the documentation):

// The check is to ensure we don't use .env in production
if (!isset($_SERVER['APP_ENV']) && !isset($_ENV['APP_ENV'])) {
if (!class_exists(Dotenv::class)) {
throw new \RuntimeException('APP_ENV environment variable is not defined. You need to define environment variables for configuration or add "symfony/dotenv" as a Composer dependency to load variables from a .env file.');
}
(new Dotenv())->load(__DIR__.'/../.env', __DIR__.'/../.env.local');
}

5) The key to override .env is this part: , __DIR__.'/../.env.local'

6) Set all environment variable (local dev database connection, so on) in the .env.local file.

Now the .env file template will not cause db connection or other errors on local dev, because the second file overrides it.

Hey Csaba B.

Thanks for sharing it! Just in case, here are the docs of local env vars: https://symfony.com/blog/ne...

Cheers!

Example:
Apache production webhost, do I understand you right that it is recommended to set the env variable via (by example):

SF-Project/public/.htaccess

SetEnv SLACK_WEBHOOK_ENDPOINT https://...
[...Symfony other stuff...]

Is this the correct way for apache?
I keep asking myself because it seems to make sense to keep this project related informations inside the project itself rather than inside an apache vhost config file.

Hey Mike P.

If the variable may change depending on the machine (server) where the project lives, then, it must be an "Environment" variable, if not, then, it can be an application's variable.

I would recommend storing your env variables inside the vhost config file instead of ".htaccess" file because it's more secure

Cheers!

Thanks for the fast reply!

Since most "shared web hosting companys" do not provide access to the apache virtual host file, whats the best solution for this case?

Hmm, nice question and to be honest I'm not totally sure but I would choose a place that is outside of the public web directory (I'm not sure if you can do that in a shared hosting)

For the environment variables, previous convention in Symfony 2 and 3, (or so I thought), was to store them in separate environment config yaml files that are ignored and not committed, but live in the config directory.

Hey Kegan,

You're right, it was app/config/parameters.yml file for server-specific parameters, which should not be committed, but there's should be another one - app/config/parameters.yml.dist which should and hold the same keys but different (dummy) values which work for dev/test environment.

Cheers!

Exactly, that's how I've always done it. Thank you for the reassuring response!

Hi, on 1:16 I don't think you meant to have the --dev on the composer call, because you are explaining how to add it for production. Thanks!

Hey Jose Diaz

Good observation, but remember that is not recommended to use it on production, maybe if you have developed a small app, and you just want to deploy it, you could rely on it so you can avoid the over head of configuring environment variables manually, but as soon as your project starts growing, you should consider removing that bundle from production, and use "your" particular method of setting up env variables

Cheers!