Restricting Access to an Entire Crud Section
Keep on Learning!
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login SubscribeSo... great! We can now restrict things on an action-by-action basis. But sometimes... it's not that complicated! Sometimes you just want to say:
I want to require
ROLE_MODERATORto be able to access any part of a CRUD section as a whole.
In that case, instead of trying to set permissions on every action like this, you can be lazy and use normal security.
For example, head to the top of QuestionCrudController. Above the class, leverage the #[IsGranted] attribute from SensioFrameworkExtraBundle. Just for a minute, let's pretend that we're going to require ROLE_SUPER_ADMIN to use any part of this section.
| // ... lines 1 - 15 | |
| use Sensio\Bundle\FrameworkExtraBundle\Configuration\IsGranted; | |
| ('ROLE_SUPER_ADMIN') | |
| class QuestionCrudController extends AbstractCrudController | |
| // ... lines 20 - 93 |
If we move over now and refresh... "Access Denied"! Yea, since these controllers are real controllers, just about everything that works in a normal controller also works inside of these CRUD controllers.
Let's undo that. Or, if you want, we can put ROLE_MODERATOR up there to make sure that if we missed any actions, users will at least need to have ROLE_MODERATOR. Since we're already logged in with that user, now... we're good!
| // ... lines 1 - 17 | |
| ('ROLE_MODERATOR') | |
| class QuestionCrudController extends AbstractCrudController | |
| // ... lines 20 - 93 |
Make sure Permissions Match Link Permissions
One thing I do want to point out is that, when you link to something, you do need to keep the permissions on that link "in sync" with the permissions for the controller you're linking to.
For example, let's temporarily remove the link permission for the menu item.
| // ... lines 1 - 24 | |
| class DashboardController extends AbstractDashboardController | |
| { | |
| // ... lines 27 - 57 | |
| public function configureMenuItems(): iterable | |
| { | |
| // ... line 60 | |
| yield MenuItem::linkToCrud('Questions', 'fa fa-question-circle', Question::class); | |
| //->setPermission('ROLE_MODERATOR'); | |
| // ... lines 63 - 66 | |
| } | |
| // ... lines 68 - 127 | |
| } |
Then, in QuestionCrudController, down on index, temporarily require ROLE_SUPER_ADMIN. This means that we should not have access.
| // ... lines 1 - 18 | |
| class QuestionCrudController extends AbstractCrudController | |
| { | |
| // ... lines 21 - 34 | |
| public function configureActions(Actions $actions): Actions | |
| { | |
| return parent::configureActions($actions) | |
| ->setPermission(Action::INDEX, 'ROLE_SUPER_ADMIN') | |
| // ... lines 39 - 43 | |
| } | |
| // ... lines 45 - 91 | |
| } |
And if we move over and refresh... that's true! We're denied access! But go back to /admin. Uh oh: the Questions link does show up. EasyAdmin isn't smart enough to realize that if we clicked this, we wouldn't have access. It's our responsibility to make sure that the permissions on our link are set up correctly.
Go change this back to ROLE_MODERATOR... and over here, we'll restore that permission. Now we're good. Our question section requires ROLE_MODERATOR and specific actions inside of it, like DELETE, require ROLE_SUPER_ADMIN.
Nice work team!
But security can go even further! Next let's hide individual fields based on permissions and even hide specific entity results based on which admin user is logged in. Whoa...
Hi! How can I see the list of predefined roles? And how can I create my own roles, for example, ROLE_EDITOR?
Thank you.