Symfony provides a security component and bundle for managing authentication and authorization in an application. It is versatile and powerful, if not a bit complicated. You can toss as many mixes of authentication and authorization configuration as you want. The important parts of the configuration cannot be overridden or added to by multiple config files, though. This makes sense for one-off applications, where you can be sure that no bundles are messing with your security configuration. However, if you’re building something like a CMS that will be used for multiple sites, where you want the CMS’s bundle to manage security, setting the configuration within the bundle will block the application itself from adding its own configuration.
One way I’ve found to work around this is to have the security configuration set on your bundles configuration extension instead of the ‘security’ extension directly, and have your bundle merge all such configurations and set them on the ‘security’ extension in PHP. If you allow this configuration node to be overridden, any number of bundles can add to it and avoid the “cannot be overwritten” error.
I will be talking about using namespaced PHP classes with static properties for configuration. Since my use was in relation to Symfony, it is important to note that the Config component should be used for everything possible, but that it can’t be used before it is instantiated.
Reasons to use namespaced static class properties for configuration:
A class can be defined in a file. When that file is included from elsewhere, the class is defined.
Once a class is defined, it is accessible anywhere after that point, regardless of scope. Like a superglobal.
Statics are variables set on a class rather than on an instance and can be accessed directly from the class. This means no variables outside of the class need to be set to work with the variables. Like a superglobal singleton.
Statics are not static and can be modified just like any other variables.
Static methods can control access and provide other behaviors you may want for working with your configuration.
Namespaces help prevent collisions of class names by essentially adding characters to a class name that make it less likely to be used elsewhere. With psr-0 / psr-4 autoloaders, the namespaces should be well controlled.
Variables can’t be namespaced, so classes (or constants or functions) are the only way to take advantage of their benefits.
Using constants and functions inside of a namespace is similar to static properties and methods of a class, except the constants are immutable and have limited data types, and there aren’t the niceties like self for the functions.
Being in PHP (as opposed to some config file format) allows use of __DIR__ (my primary need was for storing paths, and it wouldn’t be ideal to have to put in the full filesystem paths to things), string concatenation and other operations, and any other PHP behavior or values desired.
ls can have nice colors enabled to differentiate between file types easily, but the parameter is different between the BSD version (uses --color) and the GNU Linux version (uses -G). I have been setting up a “bash_profile”, among other things, to be shared between my users on all the POSIX computers I use. Some are Linux, some BSD based. I use Bash on both, and I wanted the colors from ls to be used on both with the shared “bash_profile” file. I couldn’t find anyone else’s solution for this, so I figured one out myself and will post it in case others want the same versatility. I simply test ls with one of the parameters and see if it throws an error. I then can set my aliases with the appropriate parameter. I do it like so:
ls --color > /dev/null 2>&1
if [ $? -eq 0 ]; then
alias l="ls -F --color"
alias ll="ls -lh --color"
alias l="ls -FG"
alias ll="ls -lhG"