Role based security in Sonata Admin

A while ago I posted my first blog post in what I promised would be a series of blogposts surrounding the Symfony2 Sonata Admin Bundle. Finally, I have come around to writing the second blog post, this time about role based security.

There is little information about role based security in the Sonata Admin documentation, therefore I decided to write this blogpost. The examples in this post are from my open source project Protalk.

First, let’s make sure we enable role based security, in the config.yml file add the following:

sonata_admin:
    security:
        handler: sonata.admin.security.handler.role
        information:
            EDIT: EDIT
            LIST: LIST
            CREATE: CREATE
            VIEW: VIEW
            DELETE: DELETE
            EXPORT: EXPORT
            OPERATOR: OPERATOR
            MASTER: MASTER

After that, we need to make sure we can add users. The SonataUserBundle comes already with a useradmin class, you only need to use. To be able to add, edit and delete users, add the following to config.yml:

services:
    sonata.user.admin:
        class: Sonata\UserBundle\Admin\Entity\UserAdmin
        tags:
            - { name: sonata.admin, manager_type: orm, group: protalk_user, label: User }
        arguments: [null, Sonata\UserBundle\Entity\User, null]

Now, you have the ability to add new users and assign them a role. If you look at the user add/edit screen, you will see a whole list of roles. There are 2 options to define the access rules of a user. You can just assign the correct roles to the user, there will be roles like ROLE_PROTALK_MEDIA_ADMIN_MEDIA_LIST, so you can control the access of a user based on the actions a user can do. But you can also assign only one role to the user, for example the ROLE_ADMIN and then add the following to your security.yml file:

security:
    role_hierarchy:
        ROLE_SONATA_ADMIN:       ROLE_USER
        ROLE_ADMIN:
            - ROLE_SONATA_ADMIN
            - ROLE_PROTALK_MEDIA_ADMIN_MEDIA_LIST
            - ROLE_PROTALK_MEDIA_ADMIN_MEDIA_CREATE
            - ROLE_PROTALK_MEDIA_ADMIN_MEDIA_EDIT
            - ROLE_PROTALK_COMMON_ADMIN_CATEGORY_LIST
            - ROLE_PROTALK_COMMON_ADMIN_CATEGORY_CREATE
            - ROLE_PROTALK_COMMON_ADMIN_TAG_LIST
            - ROLE_PROTALK_COMMON_ADMIN_TAG_CREATE
            - ROLE_PROTALK_MEDIA_ADMIN_SPEAKER_LIST
            - ROLE_PROTALK_MEDIA_ADMIN_SPEAKER_CREATE
        ROLE_SUPER_ADMIN: [ROLE_USER, ROLE_SONATA_ADMIN, ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH]
        SONATA:
            - ROLE_SONATA_PAGE_ADMIN_PAGE_EDIT  # if you are not using acl then this line must be uncommented

The exact roles can be guessed based on the name of the service for the admin class. For example, in our case we have defined a service called protalk.media.admin.speaker in our config.yml file. The actions that can be performed are called LIST, CREATE, EDIT and DELETE (the most important ones at least). So to determine the exact role name, simply put ROLE__.

This is it. Leave a comment if something is unclear. Otherwise, see you at my next blogpost!

This entry was posted in PHP, ProTalk and tagged , , , . Bookmark the permalink.

3 Responses to Role based security in Sonata Admin

  1. Hannah Carter says:

    Thanks for this article, it really helped me understand the roles a bit more. To me, the Sonata docs made it seem like the role had to be prefixed with ROLE_SONATA_ADMIN_, with the last part of the admin service name coming next, and then the action.

    If you could, I feel it would be very helpful if you could fork the docs, make the examples a bit more clear and then submit a PR.

    Thanks again,
    Hannah

Leave a Reply

Your email address will not be published. Required fields are marked *

*