Archives


Master Symfony2 fundamentals

Be trained by SensioLabs experts (2 to 6 day sessions -- French or English).
trainings.sensiolabs.com

Discover the SensioLabs Support

Access to the SensioLabs Competency Center for an exclusive and tailor-made support on Symfony
sensiolabs.com

Fabien Potencier
New in Symfony 2.3: Interactive Management of the parameters.yml File
by Fabien Potencier – May 07, 2013 – 17 comments

Contributed by
Christophe Coevoet
in #522.

One of the best practice when developing a Symfony application is to make it configurable via a parameters.yml file. It contains information such as the database name, the mailer hostname, and custom configuration parameters.

As those parameters can be different on your local machine, your testing environment, your production servers, and even between developers working on the same project, it is not recommended to store it in the project repository. Instead, the repository should contain a paramaters.yml.dist file with sensible defaults that can be used as a good starting point for everyone.

Then, whenever a developer starts working on the project, the parameters`.yml file must be created by using the parameters.yml.dist as a template. That works quite well, but whenever a new value is added to the template, you must remember to update the main parameter file accordingly.

As of Symfony 2.3, the Standard Edition comes with a new bundle that automates the tedious work. Whenever you run composer install, a script creates the parameters.yml file if it does not exist and allows you to customize all the values interactively. Moreover, if you use the --no-interaction flag, it will silently fallback to the default values.

Please remember that storing password or any other sensitive information in the parameters.yml file is not a good idea, and Symfony provides other ways to do the same in a more secure way.

Comments RSS

  • Guillaume Potier
    #1 Guillaume Potier said on the 2013/05/07 at 09:46
    Good idea.

    Does this bundle run on each composer install and detect that parameters.yml not sync anymore with .dist (assume that a config key has been added since last commit) and handle the new key? Same with removed keys?

    Also, in your post, you're saying storing passwords in parameters.yml is not as good/safe we might think and that Sf provides other ways, could you add a link to more info, refs? I'd be curious to know.

    Best
  • Christophe Coevoet
    #2 Christophe Coevoet said on the 2013/05/07 at 09:53
    @guillaume Yes it does. The main reason I created it was precisely to update the yml file when new keys are added in the dist file.
    by default, it also removes old keys but this can be disabled
  • Mike Meessen
    #3 Mike Meessen said on the 2013/05/07 at 10:06
    While this is one way to handle environment-local configuration, we have come up with another way, which I think, might be slightly more flexible:

    We actually check in parameters.yml. It contains sensible defaults and placeholders for sensitive configuration (e.g. Amazon S3 Credentials, etc.). Then, we have an additional file parameters_local.yml, which contains configuration values that override those in parameters.yml. We achieved this by adding just a couple of lines in AppKernel.php.

    This has quite a few advantages:

    - We still have a 'template' file which lists all available parameters
    - We instantly have an (almost) out-of-the-box preconfigured system with sensible defaults
    - While developing, we can add configuration parameters to the system without having to explicitly define them in every dev / test / prod environment (!)
    - While we have quite a lot configuration parameters, we can look at an environment's parameters_local.yml file and instantly see what has been customized in that environment.
    - We don't need any special / interactive tool for generating our configuration files ;)

    Maybe such an approach could be considered as an alternative to the proposed new feature? - or maybe not ^^ Just wanted to share :)

    Best regards,
    Mike
  • Matthieu Moquet
    #4 Matthieu Moquet said on the 2013/05/07 at 10:22
    @Mike You even don't have to change your AppKernel to do that.
    We also have a similar configuration to avoid repeating default parameters. For instance, you can simply add in your config.yml :

    imports:
    - { resource: parameters_dist.yml } # versionned file
    - { resource: parameters_local.yml, ignore_errors: true } # git-ignored file

    `parameters_dist.yml` only contains (all) default parameters like db user/pass = root/root, and parameters_local.yml can overwrite everything. The ignore_errors=true allow us to ignore if file is missing (may be usefull for local env).

    This is handy for local/test/staging env, but of course, we almost redefine everything for prod ;)
  • Anton Babenko
    #5 Anton Babenko said on the 2013/05/07 at 10:22
    "Please remember that storing password or any other sensitive information in the parameters.yml file is not a good idea, and Symfony provides other ways to do the same in a more secure way."

    Is using env variables more secure ? Or what are the secure alternatives for keeping, let's say, db user/password instead of parameters.yml?
  • Guillaume Potier
    #6 Guillaume Potier said on the 2013/05/07 at 10:36
    Thanks @christophe for your answer. I've added your bundle, it works like a charm.

    What about my second question, the "more secure way to handle sensitive info" ? :)

    Best
  • Ardian Yuli Setyanto
    #7 Ardian Yuli Setyanto said on the 2013/05/07 at 10:48
    +1 for info or reference how to store password in a more secure way,
  • Matthieu Moquet
    #8 Matthieu Moquet said on the 2013/05/07 at 10:49
    @guillaume: like @anton mentioned it, I think he's talking about env variables (SYMFONY__MY_PARAM), which are maintained by a root/sysadm user and not by the _www user (ie. not the same user which run the code, and neither the same directory).
  • Matthieu Napoli
    #9 Matthieu Napoli said on the 2013/05/07 at 11:25
    We use the same solution than Mike, it's quite effective since you can end up with an empty "parameters_local.yml" if every default setting works for you.
  • Javier Eguiluz
    #10 Javier Eguiluz said on the 2013/05/07 at 12:00
    The "more secure way to handle sensitive info" is explained in the following cookbook recipe:

    http://symfony.com/doc/master/cookbook/configuration/external_parameters.html
  • Konrad Mohrfeldt
    #11 Konrad Mohrfeldt said on the 2013/05/07 at 14:16
    wouldn’t parameters.dist.yml be the smarter choice for the filename, as it doesn’t break auto-highlight features of editors that are based on file extensions?
  • Sanjay
    #12 Sanjay said on the 2013/05/07 at 15:44
    Good job guys.
    But I want to know more about
    "Symfony provides other ways to do the same in a more secure way." anyone having idea about this one ?

    Best regards,
    Sanjay
  • Mike Meessen
    #13 Mike Meessen said on the 2013/05/07 at 17:09
    Good feedback @Matthieu! I guess it was the ignore_errors that kept me from importing it in the config right away, I didn't know that one. I guess I'm going to change that to simplify our setup :)
  • Luis Cordova
    #14 Luis Cordova said on the 2013/05/08 at 14:58
    why the bundle's name is not even mentioned?
  • Stephen Ostrow
    #15 Stephen Ostrow said on the 2013/05/09 at 17:31
    We ran into an issue where a hosting environment we were using had the credentials and other information in environmental variables. When looking at it this is actually a good practice and can be done easily when spinning up EC2 instances as well.

    The problem we had was having symfony use these environmental variables. I ended up writing up a bash script which would take the variables and populate the parameters.ini file; however, I wish I had time to make a cleaner solution. I could see having this new script allow you to specify the values while using --no-interaction. But more ideally would be a way to have symfony use the environmental variables in place of the parameters.ini file. Maybe a way of using %ENV.db_username% within parameters.ini
  • Christophe Coevoet
    #16 Christophe Coevoet said on the 2013/05/09 at 23:10
    @Stephen Incenteev ParameterHandler (which is the library mentionned in the blog post) supports it (except it supports parameters.yml, not parameters.ini). See its readme: https://github.com/Incenteev/ParameterHandler/
  • kazem
    #17 kazem said on the 2013/06/18 at 18:31
    This is Best