I'm developing an admin dashboard with different areas, where different users may have different permissions. For example:

  • News
    • John: edit, view, add, remove;
    • Carlos: edit, view;
    • Mario: --;
  • Support
    • John: view;
    • Carlos: edit, view;
    • Mario: edit, view, add, remove;

The way I control this permission is via JSON array, containing each area and list of permission. I save this in my MySql database (serializing first) and also on the localStorage. This way I can check on the frontend but also make a final validation on the server side, via PHP.

JSON example:

    "area": "news",
    "permission": [
        {"field": "access", "value": true},
        {"field": "read", "value": true},
        {"field": "edit", "value": true},
        {"field": "add", "value": true},
        {"field": "remove", "value": true}
    "area": "support",
    "permission": [
        {"field": "access", "value": true},
        {"field": "read", "value": true},
        {"field": "edit", "value": false},
        {"field": "add", "value": false},
        {"field": "remove", "value": false}

I'm with doubts about this system because, first, I never did anything like this and didn't found any example, so I don't know if this is the proper way to do this. Also, I'm storing this as JSON because there are admin users who need to edit (with checkbox) this permissions, so it's easier to display this on the frontend.

But I'm very open to change this method based on other criterias you think it's better. I just want to have it security first and also easy to maintain.


2 Answers 2


Disclaimer: I am by not way an expert on these kind of matters, I'm just sharing how me and my senior are doing our current project.


Your design looks solid enough, but I would think about how I would hold these permissions in a table.

lets say we have a users table

user_id | name | password
      0 | John |     ****

I can see 2 possible ways you would extend our database to hold these permissions.

You can add permission columns that tell what each user can do

user_id | name | password| perm1 | perm2 | ... |permn
      0 | John |     ****|     Y |     N |     |    Y

That will entail having a lot of columns and a messy design. on the plus side you will have the granularity to dictate exactly what one can and cannot do.

You can however add the concept of roles to your design.

You can make a roles table, define the types of user roles (and the kind of permissions they provide) in your application and just give each user a role

user_id | name | password|  role_id
      0 | John |     ****|        1

And the roles table

role_id | role_name  | perm1 |....| permn
      0 | Admin      |     Y |    |    Y
      1 | Regular    |     N |    |    Y

This way you create a separation of concerns for your users table, instead of placing all your user data into one table that may grow over time (handling dozens of columns in a table is no fun), you can place separate relevant user data across multiple tables. it will also keep your queries short.

(This is similar to how Java web applications provide privileges/permissions to users)


For your client view, you can hold a session object that describes the current user, you can use the role value to tell your php scripts what parts of your templates you want to generate for your user.

Example (blade):

@if (user($role) === 'admin')
    <button id="dontclickme">History eraser button</button>
  • The problem to create roles is I'll not have custom control for each user permission, or I would have a lot of roles, to match a lot of possible combinations. But I think we can work around your first idea of table, It looks promising! maybe something like: user_id | area | edit | read | del | add and then, for each user and each area There would be a better control. What do you think? Dec 29, 2016 at 12:15
  • if it's just for permissions then sure. again, consider what will happen when you'll be required to add more features and conditions for a user. that table will bloat in width. what about slightly modifying my 2nd idea? instead of having a table with predefined roles with combinations, have a table with a row of combinations per each user (the primary key would also act as foreign key to user_id)
    – svarog
    Dec 29, 2016 at 12:40

So, Your implementation for the front-end doesn't seem bad to me. You may want to think of how you are going to use the permissions with js specifically, and see if you are happy with the structure of the json based on that.

WRT to the back-end, I try not to store JSON directly in the db. If you have to do any work on that data directly through the db it will be very inefficient, especially as your number of users grows.

In general with something like this, I would first see if you find something that fits your needs in composer. If nothing does, you may want to look at a few packages and see if you can find some inspiration if you have doubts of your own implementation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.