SUBSCRIBE VIA RSS


Subscribe to our feed

Symfony Experts

Symfony Experts
If you have an urgent question for a symfony-related issue, this is the place to ask.

Topics

Stack Overflow


The old fashioned way

RECENT TUNES

August 10, 2009 – 10:27am symfony configuration settings, “default” versus “all”

It’s hard to keep track of the difference between the “all” parameter heading and the “default” parameter heading in your security configuration files. The way to remember it is that “default” is just that — a value for when there are no other values set, including one for “all”.

The way symfony parses its configuration yml files, it does a deep merge and makes the settings for “all” override the settings for “default”. So if you had an “all” setting in your application’s security.yml, and then a “default” setting in your module, the “all” setting would still take precedence even though mentally we like to think of module settings always overriding what is found in the application-wide files.

Here is the snippet in of code that actually does this processing, (it’s in a file called sfSecurityConfigHandler.class.php). Here, $myConfig is an array with action names as the keys, and the value is an array containing the “is_secure” parameter along with any specific credentials required.

$myConfig['all'] = sfToolkit::arrayDeepMerge(
      isset($myConfig['default']) && is_array($myConfig['default']) ? $myConfig['default'] : array(),
      isset($myConfig['all']) && is_array($myConfig['all']) ? $myConfig['all'] : array()
    );

So, when symfony is parsing all of those security.yml files, you end up with a bunch of entries for all of your various actions:

$myConfig['login'] = array('is_secure' => false);
$myConfig['mySecureAction'] = array('is_secure' => true, 'credentials' => array(...));

and then symfony creates the “all” setting, based on what it finds for “default” and “all”, which it will use for any action that doesn’t have an explicit security setting. This $myConfig array is what eventually gets saved into the auto-generated [module]_config_security.yml.php files inside your cache directory.

So, if you are having trouble getting the right javascript or stylesheets to load in your view, or having trouble securing a page even though you are certain it’s listed in your security.yml file, check to see if there is an existing “all” configuration that might be overriding your local “default”.

Posted by in  Web Development   |  

Comments are closed.