Skip to main content
This example demonstrate the authorization structure for Facebook groups, which enables users to perform various actions based on their roles and permissions within the group.

Schema | Open in playground

Brief Examination of the Model

The model defines several entities and relations, as well as actions and permissions that can be taken by users within the group. Let’s examine them shortly;

Entities & Relations

  • user entity represents a user in the Facebook.
  • group entity represents the Facebook group, and it has several relations including member, admin, and moderator to represent the members, admins, and moderators of the group. Additionally, there are relations to represent the posts and comments in the group.
  • post entity represents a post in the Facebook group, and it has relations to represent the owner of the post and the group that the post belongs to.
  • comment entity represents a comment on a post in the Facebook group, and it has relations to represent the owner of the comment, the post that the comment belongs to, and the comment itself.
  • like entity represents a like on a post in the Facebook group, and it has relations to represent the owner of the like and the post that the like belongs to.
  • poll entity represents a poll in the Facebook group, and it has relations to represent the owner of the poll and the group that the poll belongs to.
  • file entity represents a file in the Facebook group, and it has relations to represent the owner of the file and the group that the file belongs to.
  • event entity represents an event in the Facebook group, and it has relations to represent the owner of the event and the group that the event belongs to.

Permissions

We have several actions attached with the entities, which are limited by certain permissions. For example, the create_group action can only be performed by a member, as follows:

Creating a group permission

Another example would be given from the edit_post action in the post entity, which specifies the permissions required to edit a post in a Facebook group.

Editing a post permission

An owner of a post can always edit their own post. In addition, members who are defined as admin of the group - which the post belongs to - can also edit the post. Since most entities are deeply nested together, we also have multiple hierarchical permissions.

Nested Hierarchies

For example, we can define a permission “view_comment” if only user is owner of that comment or user is a member of the group which the comment’s post belongs.
The post.group_member refers to the members of the group to which the post belongs. We defined it as action in post entity as,
Permissions can be inherited as relations in other entities. This allows to form nested hierarchical relationships between entities. In this example, a comment belongs to a post which is part of a group. Since there is a ‘member’ relation defined for the group entity, we can use the ‘group_member’ permission to inherit the member relation from the group in the post and then use it in the comment.

Relationships

Based on our schema, let’s create some sample relationships to test both our schema and our authorization logic.

Test & Validation

Finally, let’s check some permissions and test our authorization logic.
According to what we have defined for the ‘RSVP_to_event’ action, users who are either the owner of event:1 or a member of the group that belongs to event:1 can grant access to RSVP to the event.According to the relation tuples we created, user:4 is not the owner of the event. Furthermore, when we check whether user:4 is a member of the only group (group:1) that event:1 is part of (event:1#group@group:1), we see that there is no member relation for user:4 in that group.Therefore, the user:4 RSVP_to_event event:1 check request should yield a ‘false’ response.
According to the relation tuples we created, user:5 is not the owner of the comment. But member of the group:1 and thats grant user:5 (group:1#member@user:5) access to perform view the comment:1. In particularly, comment:1 is part of the post:1 (comment:1#post@post:1) and post:1 is part of the group:1 (post:1#group@group:1). And from the action definition on above model group:1 members can view the comment:1.Therefore, the user:5 view_comment comment:1 check request should yield a ‘true’ response.
Let’s test these access checks in our local with using permify validator. We’ll use the below schema for the schema validation file.

Using Schema Validator in Local

After cloning Permify, open up a new file and copy the schema yaml file content inside. Then, build and run Permify instance using the command make serve. Running Permify Then run permify validate {path of your schema validation file} to start the test process. The validation result according to our example schema validation file: Screen Shot 2023-04-16 at 15 53 06

Need any help?

This concludes the demonstration of the authorization structure for Facebook groups. To install and implement this see the Set Up Permify section. If you need any kind of help, our team is happy to help you get started with Permify. If you’d like to learn more about using Permify in your app or have any questions about it, schedule a consultation call with one of our account executives.