Popular posts

I would love to hear more about it. Is it different than what I described below?

Serdar Sanri I am not quite sure if the basic concept is entirely the same. Let me elaborate:

For SQL, you may have several tables: users, groups, user_group_map, permission_keys, permission_map.

If a user is logged on and a script requests to know if the user has permission, the app has to

1. Poll the user's groups from the user_group_map table
2. Poll the permissions for all groups and the user themself from the permission_map table, where they actually have the key assigned
3. Check if the DB returned any result; if yes, the user has permission

It may be possible to create a single query to do this.

For NoSQL, I'd store user permissions and groups on the user and then just fetch all permissions and permissions on the groups, then filter for the required permission key.

Yeah sounds like similar concept. In my case I have Laravel in backend api. I have users, permissions, groups main tables which holds the main definitions. Then I have relation tables for group_user many to many and group_permissions. one to many. So each user can belong to many groups, and each group has multiple permissions. And along with these definitions I have api oauth scopes defined by permissions. When I careate different routes, I add necessary scopes to access that route.

$route->get('user/profile/{id}, 'UserController@loadUserById')->scopes(['view_user'])

Then a middleware I created, finds current logged in user with auth token and collects all permissions user may have by loading groups it belongs to. then finally compares scopes to user's permissions inherited from groups. If fails returns 403 with user friendly message, or continues processing controller.

It is not a perfect solution but does what it needs to do.