FrostByteOrg/FrostByte

FROS - Server and Channel Based Permissions

Closed this issue · 1 comments

Feature Description

Server and channel based permission structures, these should be stored as a set of bits to set permissions, as such we can use enums to explicitly refer to these permissions in code and still maintain the ability to evaluate them in postgres

Use Case

These permissions should be applied to roles that can be created by users that have the permission to (by default, this should be the server owner ONLY, until they grant the permission outward to other members)

Due to the permissions being assigned via bit flags, we can easily evaluate the user permissions on Postgres' end to implement in our authorization flows for the following operations:

Server Encompassing

Invite links

  • User would need the dedicated permission create invites to generate invite URLs (allow write access to the invites table provided they have this permission in a server

Channel Management

  • User would require the manage channels permission to create/update/delete channels (write to channels) within the server they have been granted this permission to

Server Role Management

  • User would require the permission manage roles to create/update/delete roles
  • This requires a more nuanced approach as we cannot let users make roles that either
    • Have their current highest ranked permission
    • Have permissions they themselves do not have

Managing Users

  • User would require the manage users permission to perform operations such as kicking/banning members, requires kick/ban perms respectively. User should not be able to kick/ban a member at their permission level or higher (write to server_users)

Managing the Server

  • User would require the manage server permission to do the following operations:
    • Change server name
    • Change server image
    • Invalidate invite links

Channel Encompassing

Additionally, we'd require channel permissions (note that these should be linked ONLY to roles for simplicity) to do the following:

  • Allow/Deny users with a role to send messages in a channel
  • Allow/Deny users with a role to send images in a channel
  • Allow/Deny users with a role to send URLs in a channel

Following this up, I believe we may improve on competing implementations of this by using the highest role level's permission to allow/deny. For example:

  • A user has two roles, role a, which grants permissions to speak in general, and role b, which denies the ability to speak in general
  • If a is ranked higher than b, the user should be allowed to speak in general
  • If b is ranked higher than a, the user should not be allowed to speak in general

Prerequisites

This requires further modifications to our SQL table structure and constraints to accomodate for and perform:

  • Server Ownership
  • Creation of a channel_permissions table
  • Creation of a server_bans table which has a record of all bans in the server
  • Auto-cascade when dropping from the following root structures (all other tables will have some form of dependency on these)
    • profiles
    • servers
    • channels

Any additional remarks:

N/A

Very clean

Much nice

Most Enjoyed.

image