Endpoints
CometChat provides two types of access control permissions:
- RBAC (Role-Based Access Control) Permissions applied globally based on the user’s assigned role
- SBAC (Scope-Based Access Control) Permissions applied within group context based on the member’s scope
RBAC (Role-Based Access Control)
Role-Based Access Control (RBAC) enables fine-grained control over what actions a user can perform and what data they can access, based on the role assigned to them (for example:doctor, patient, buyer, seller).
How RBAC Works
- Permissions are configured per role
- Each permission has a default value
- Explicitly configured permissions override defaults
- RBAC permissions are evaluated at runtime for every API request
- If a permission evaluation fails, the API returns an
ERR_PERMISSION_DENIEDerror
- Binary permissions (
allow/deny) - Conditional permissions using additional configuration keys such as
mode,allowedRoles, andallowedMessageTypes
- User relationships (all users vs friends)
- Sender or receiver roles
- Message categories and types
RBAC Data Types
RBAC Permission Structure
Each RBAC permission follows this structure:RBAC Permission Value Behavior
When an array permission (e.g.,allowedRoles, mimeTypes) has a value of null:
- It means no restriction - all values are allowed
- This is equivalent to an empty array
[]
allow / deny values:
allow: The action is permitteddeny: The action is blocked, returnsERR_PERMISSION_DENIED
mode values:
all: Action applies to all usersfriends: Action is restricted to friends only
RBAC Permissions
1. Users
2. Messages
3. Message Thread
4. Message Reactions
5. Calls
6. Conversations
7. Groups
RBAC Example Configuration
The following example denies the sendMessage permission for the user role. When applied, users with this role will not be able to send messages and will receive anERR_PERMISSION_DENIED error.
RBAC Permission Evaluation Order
- Explicitly configured permission for the role which has the highest priority
- Permission default value (from permission definition)
SBAC (Scope-Based Access Control)
Scope-Based Access Control (SBAC) enables fine-grained control over what actions a user can perform within a group, based on their member scope (for example:admin, moderator, participant).
How SBAC Works
- Permissions are configured per scope within group context
- Each permission has a default value
- Explicitly configured permissions override defaults
- SBAC permissions are evaluated at runtime for every group-related API request
- If a permission evaluation fails, the API returns an
ERR_PERMISSION_DENIEDerror - SBAC permissions are evaluated alongside RBAC rules. For group operations, both must allow the action
- Binary permissions (
allow/deny) - Conditional permissions using additional configuration keys such as
allowedScopes,allowedMessageTypes, andmimeTypes
- Member scopes within the group
- Message categories and types
- Group-specific message history access
SBAC Data Types
SBAC Permission Structure
Each SBAC permission follows this structure:SBAC Permission Value Behavior
When an array permission (e.g.,allowedScopes, mimeTypes) has a value of null:
- It means no restriction - all values are allowed
- This is equivalent to an empty array
[]
allow / deny values:
allow: The action is permitteddeny: The action is blocked, returnsERR_PERMISSION_DENIED
SBAC Permissions
1. Groups
2. Members
3. Messages
4. Message Thread
5. Message Reactions
6. Calls
SBAC Example Configuration
The following example denies the sendMessage permission for the participant scope. When applied, group members with the participant scope will not be able to send messages in the group and will receive anERR_PERMISSION_DENIED error.
SBAC Permission Evaluation Order
- Explicitly configured permission for the scope which has the highest priority
- Permission default value (from permission definition)