> Symfony 5 > Symfony 5 Security: Authenticators
Login to bookmark this video
Buy Access to Course
22.

Dynamic Roles

|

Share this awesome video!

|

Keep on Learning!

Start your All-Access Pass

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

Earlier, we talked about how the moment a user logs in, Symfony calls the getRoles() method on the User object to figure out which roles that user will have:

156 lines | src/Entity/User.php
// ... lines 1 - 12
class User implements UserInterface, PasswordAuthenticatedUserInterface
{
// ... lines 15 - 26
/**
* @ORM\Column(type="json")
*/
private $roles = [];
// ... lines 31 - 78
/**
* @see UserInterface
*/
public function getRoles(): array
{
$roles = $this->roles;
// guarantee every user at least has ROLE_USER
$roles[] = 'ROLE_USER';
return array_unique($roles);
}
// ... lines 90 - 154
}

This method reads a $roles array property that's stored in the database as JSON... then always adds ROLE_USER to it.

Until now, we haven't given any users any extra roles in the database... so all users have just ROLE_USER. You can see this in the web debug toolbar: click to jump into the profiler. Yup, we have ROLE_USER.

This is too boring... so let's add some true admin users! First, open config/packages/security.yaml... and, down under access_control, change this to once again require ROLE_ADMIN:

54 lines | config/packages/security.yaml
security:
// ... lines 2 - 50
access_control:
- { path: ^/admin, roles: ROLE_ADMIN }
// ... lines 53 - 54

Remember: roles are just strings that we invent... they can be anything: ROLE_USER ROLE_ADMIN, ROLE_PUPPY, ROLE_ROLLERCOASTER... whatever. The only rule is that they must start with ROLE_. Thanks to this, if we go to /admin... access denied!

Populating Roles in the Database

Let's add some admin users to the database. Open up the fixtures class: src/DataFixtures/AppFixtures.php. Let's see... down here, we're creating one custom user and then 10 random users. Make this first user an admin: set roles to an array with ROLE_ADMIN:

60 lines | src/DataFixtures/AppFixtures.php
// ... lines 1 - 15
class AppFixtures extends Fixture
{
public function load(ObjectManager $manager)
{
// ... lines 20 - 47
UserFactory::createOne([
'email' => 'abraca_admin@example.com',
'roles' => ['ROLE_ADMIN']
]);
// ... lines 52 - 57
}
}

Let's also create one normal user that we can use to log in. Copy the UserFactory code, paste, use abraca_user@example.com... and leave roles empty:

60 lines | src/DataFixtures/AppFixtures.php
// ... lines 1 - 15
class AppFixtures extends Fixture
{
public function load(ObjectManager $manager)
{
// ... lines 20 - 47
UserFactory::createOne([
'email' => 'abraca_admin@example.com',
'roles' => ['ROLE_ADMIN']
]);
UserFactory::createOne([
'email' => 'abraca_user@example.com',
]);
// ... lines 55 - 57
}
}

Let's do it! At your terminal, run:

symfony console doctrine:fixtures:load

When that finishes... spin over and refresh. We got logged out! That's because, when the user was loaded from the session, our user provider tried to refresh the user from the database... but the old user with its old id was gone thanks to the fixtures. Log back in.... with password tada and... access granted! We rock! And in the profiler, we have the two roles.

Checking for Access inside Twig

In addition to checking or enforcing roles via access_control... or from inside a controller, we often also need to check roles in Twig. For example, if the current user has ROLE_ADMIN, let's a link to the admin page.

Open templates/base.html.twig. Right after this answers link... so let me search for "answers"... there we go, add if, then use a special is_granted() function to check to see if the user has ROLE_ADMIN:

51 lines | templates/base.html.twig
<!DOCTYPE html>
<html>
// ... lines 3 - 14
<body>
<nav class="navbar navbar-expand-lg navbar-light bg-light px-1">
<div class="container-fluid">
// ... lines 18 - 26
<div class="collapse navbar-collapse" id="navbar-collapsable">
<ul class="navbar-nav me-auto mb-2 mb-lg-0">
// ... lines 29 - 31
{% if is_granted('ROLE_ADMIN') %}
// ... lines 33 - 35
{% endif %}
</ul>
// ... lines 38 - 40
</div>
</div>
</nav>
// ... lines 44 - 48
</body>
</html>

It's that easy! If that's true, copy the nav link up here... paste.. send the user to admin_dashboard and say "Admin":

51 lines | templates/base.html.twig
<!DOCTYPE html>
<html>
// ... lines 3 - 14
<body>
<nav class="navbar navbar-expand-lg navbar-light bg-light px-1">
<div class="container-fluid">
// ... lines 18 - 26
<div class="collapse navbar-collapse" id="navbar-collapsable">
<ul class="navbar-nav me-auto mb-2 mb-lg-0">
// ... lines 29 - 31
{% if is_granted('ROLE_ADMIN') %}
<li class="nav-item">
<a class="nav-link" href="{{ path('admin_dashboard') }}">Admin</a>
</li>
{% endif %}
</ul>
// ... lines 38 - 40
</div>
</div>
</nav>
// ... lines 44 - 48
</body>
</html>

When we refresh... got it!

Let's do the same with the "log in" and "sign up" links: we only need those if we are not logged in. Down here, to simply check if the user is logged in, use is_granted('ROLE_USER')... because, in our app, every user has at least that role. Add else, endif, then I'll indent. If we are logged in, we can paste to add a "Log out" link that points to the app_logout route:

55 lines | templates/base.html.twig
<!DOCTYPE html>
<html>
// ... lines 3 - 14
<body>
<nav class="navbar navbar-expand-lg navbar-light bg-light px-1">
<div class="container-fluid">
// ... lines 18 - 26
<div class="collapse navbar-collapse" id="navbar-collapsable">
// ... lines 28 - 38
{% if is_granted('ROLE_USER') %}
<a class="nav-link text-black-50" href="{{ path('app_logout') }}">Log Out</a>
{% else %}
<a class="nav-link text-black-50" href="{{ path('app_login') }}">Log In</a>
<a href="#" class="btn btn-dark">Sign up</a>
{% endif %}
</div>
</div>
</nav>
// ... lines 48 - 52
</body>
</html>

Cool! Refresh and... so much better. This is looking like a real site!

Next, let's learn about a few special "strings" that you can use with authorization: strings that do not start with ROLE_. We'll use one of these to show how we could easily deny access to every page in a section except for one.