In CloudCode, is there any utility function which I can determine that the current user belongs to a certain role?
Assume the following role hierarchy Admin->Manager->User
If I added user1 to the Admin role, this means if in cloud code if I query all the roles this user belongs to, then I will get immediate list of roles not hierarchy. I am wondering if there is a utility function that helps with this issue?
Related
Good Evening, it is possible that in SPATIE-LARAVEL-PERMISSION the following:
Some function or way that I receive an id of a Role and with that id I list all the permissions that are assigned to that role. I'm looking but I didn't find an answer. sorry for the inconvenience thank you
As described here in the docs, you can get all permissions of a role with the permissions relation
use \Spatie\Permission\Models\Role;
Role::find($id)->permissions;
For my own understanding, I'm writing a Hierarchical Discretionary Access System. It is not DAC, it is more akin to Discretionary RBAC, but those details do not matter for the question at hand.
Each user has a certain Role; each Role has a certain set of permissions.
Each Role is organised in a hierarchical tree-like structure: the role named root has all permissions; child roles of root have a subset of the permission of their parent role.
Schematic views of the above:
Let's say that a user with the role named manager decides to delegate the permission named set_salary to a user with the role named programmer, who subsequently delegates this permission to the user with the role named intern.
Somebody decides to fire said user with the role named manager. As a result, the role named manager is revoked from said user. What is more, all permissions delegated by said user also need to be revoked.
So my question is:
Is there a data structure which facilitates easy identification of:
the chain of permissions delegated by a certain subject within a hierarchical tree structure;
whether or not a certain permission has been delegated to a certain subject?
How about an adjacency list ?
Or in other words, 'a list of linked lists', similar to how we use it in representing graphs.
Each user can be associated with a delegation linked list.
A node of the delegation linked list can be of the form <permissionId, userId>, denoting that the owner of the linked list has delegated the permission permissionId to the user userId. Then we can go through the linked list of the user userId and repeat the same process recursively until we find a user whose delegation linked list is empty.
This algorithm is basically the same as Depth-first search.
This model can't support delegation of permission per a user like you described for manager -> programmer -> intern situation. Permissions are set for a role and setting new permission for a role effects all users that has that role.
To support permission delegation per a user, new relation is needed that describes delegation. Data needed to describe it is: which user gave permission, which user received permission and permission that is delegated. Like, relation delegatedPermission with columns:
giveUserId
receiveUserId
permissionId
This question is really made of two parts.
Using Parse, I'd like to have the following [simplified] scheme, where I have Users who are part of secret groups, and there are discussion that can appear across a few groups at one. That is Users who are part of Group A also are added to the GroupA role, and have access to discussions in Group A.
My trouble is, when I create a new discussion and tell it the groups it should appear in, how do I query for the roles and add them to the Discussion as well? I'm really fuzzy on this roles/ACLs business, even after reading extensively.
User(firstname, lastname)
Group(members, secrets)
Discussion (groups, note, comments)
Create a Role when you create a Group. Assign a pointer from the Group to the Role. Set the ACL for the Group to the Role (for write, it can be public read or whatever you want). When you add users to the Group, add them to the Role so they have access through the ACL.
For your Discussion you need to add all of the appropriate Roles from all of the Groups to the ACL list so that all of the users in all of those Roles have access.
I am not a DBA, but I own a schema which hundreds of people access. For convenience, I created some roles, and assigned users to them. Since I own the schema and created the role, I feel like I should be able to quickly list all of the people in that role. Since I'm not the dba, I can't do:
SELECT * FROM DBA_ROLE_PRIVS;
The only way I can verify that I added users to the role is for me to check the orginal script I used to add users to the role. Am I missing something? I can list all of the objects the role has access to via:
SELECT * FROM role_tab_privs
WHERE OWNER = '<me>';
But I just can't see who gets to see those objects.
Thanks for any assistance!
Mike
You can try USER_SYS_PRIVS, USER_TAB_PRIVS, USER_ROLE_PRIVS
... where ROLE = 'whatever';
More info, and non-DBA views: here
I may be thinking about this wrong, but shouldn't it be a very common thing to need to check if a user belongs to a certain group? For example, if you want to show a certain menu item only to "Administrators", shouldn't there be a way within my view file to easily check if the user belongs to that group?
I see that there is a inGroup() function on the user, but this requires that you first fetch the group object, and pass it into the function, rather than simply passing the group name, for example, $user->inGroup('Administrators');. I also realize I could write my own method to accept the group name, look it up, and then use that in the exiting inGroup() method.
However, the fact that this is not much more obvious in the docs makes me believe I am thinking about it in the wrong way.
Would the preferred way be to give the "Administrators" group an "admin: 1" permission, and therefore just check if the user has that permission rather than checking if they are in the group?
If so, I am struggling to see the value of a group at all since you aren't able to easily use them to determine access; instead, you need to use the individual permissions that the group contains.
You can check to see if a user belongs to a group easily:
$user = Sentry::findUserById(1);
$adminGroup = Sentry::findGroupByName('Admin');
$isAdmin = $user->inGroup($adminGroup);
However the best approach is to use permissions. You can setup an 'Admin' group with permissions to 'manage user accounts'. You then simply check to see if the user has permission to 'manage user accounts' as opposed to checking whether they belong to the Admin group.
In my 'group' table i have a row like this:
id | name | permissions
1 | Admin | {"manageUserAccounts":1}
I can now check whether a user has permission to 'manageUserAccounts' with the following:
$user = Sentry::findUserById($userId);
if ($user->hasPermission('manageUserAccounts') {
print 'You can manage user accounts';
}
else {
print 'Oops, you cant manage user accounts';
}
Note that the 'user' table is connected to the 'group' table via the user_groups table.
See the Sentry documentation for more info on how to fine grain permissions. It's quite powerful.