Alex Makdessi has a post on his Medium.com site kicking off a series of posts taking a deeper look into the Symfony DependencyInjection component. In this first part of the series he takes some of the "first steps" with the container.

this article, we’re going to dive into Symfony’s dependency injection component. We will use it from scratch, out of the Symfony framework, with the minimum of external dependencies. You can code along with me while reading this article, each steps will be detailed so you can easily follow.

He starts off the tutorial by creating a new project and including the DependencyInjection (DI) component via Composer (as well as symfony/var-dumper for debugging). He then starts in on the code showing how to make a ContainerBuilder instance to hold the object instance for reuse. With the container created, we now need something to use it. He creates a basic piece of functionality that works similar to the "voters" included with Symfony's security component to determine if a user has a certain role. He first creates this as a stand-alone tool but then refactors it so that the access manager and post voter objects are pulled from the dependency injection container rather than made manually.

On the Happyr.com Developer blog Tobias Nyholm has written up a tutorial showing how you can use functionality included in the Symfony framework to define access control rules in a database using voters and values stored in the database.

I was recently at a PHP conference in Odessa where I met many great developers. One of them asked me a question, that the answer was not obvious. His use case was that he wanted to use Symfony's Access Control configuration to restrict access in his application. But he also wanted to configure the rules dynamically.

Since all the configuration in Symfony is cached with the container for performance reasons, we could obviously not allow a use a database to somehow “print” new configuration. We need to do something smarter.

Voters are a part of the Symfony security component and are set up as a service in the Symfony DI container. When a route is defined in the access_control section, the matching voter is called and the access granted/denied state is determined by values from the token and subject provided (from the database).

On the Stovepipe Systems blog author Iltar van der Berg has retuned with a continuation of his series on Symfony security basics with this new post covering voters and roles.

In my previous blog post I've explained the basics of authentication, authorization and how this is dealt with in Symfony. Due to the size of the post, I've left out several important topics such as roles and voters; Both an equally important part of authentication and authorization. A common misconception is that roles should be used to check permissions. In fact, they should definitely not be used to check permissions!

He goes on to explain where "roles" come into the process of authentication (not authorization) and how they describe something about the user of the system. With that defined he moves on to the "voters": functionality that "vote" on attributes related to the user/request/resource/etc. and return a pass or fail decision based on their logic. He explains why voters are probably more what most developers are looking for and some reasons to use them over roles. He then ends the post showing how to create your own custom voter and configure it into your application.