Concordia implements a sophisticated role-based access control (RBAC) system combined with attribute-based access control (ABAC) to manage user permissions across the platform.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/Ishaq74/concordia/llms.txt
Use this file to discover all available pages before exploring further.
Overview
The permission system is built using Better Auth’s access control plugin and extends it with Concordia-specific roles and permissions. The system supports:- Multi-role assignment: Users can hold multiple roles simultaneously
- Hierarchical permissions: Permissions are organized by domain (places, articles, forum, etc.)
- Contextual access control: Some permissions require additional context (ownership, organization membership, etc.)
- Privilege escalation prevention: Built-in safeguards against unauthorized role changes
User Roles
Concordia defines seven distinct roles, each with specific permissions and responsibilities.Anonyme (Anonymous)
Description: Non-authenticated visitors Access:- Public consultation of places, articles, forum threads, classifieds, services, events, and trails
- No ability to create content or interact
- Read-only access to public information
Citoyen (Citizen)
Description: Default role for all authenticated users Capabilities:- Manage personal profile
- Create and manage reviews, comments, forum posts
- Send and receive private messages
- Create and manage classifieds, events, groups, galleries
- Access personal wallet and make transactions
- Create organizations and projects
- Enroll in education modules
- Participate in volunteer projects and funding campaigns
permissions.ts:178-237):
Propriétaire (Owner)
Description: Citizens who manage one or more establishments or places Additional Capabilities:- Submit and manage place listings
- Update place information and attributes
- Manage service availability and bookings
- Respond to reviews
- Access booking revenue
- Manage organization-level resources
permissions.ts:238-252):
Auteur (Author)
Description: Citizens who publish editorial content Capabilities:- Create and manage blog articles
- Publish content via back-office
- Link articles to places and categories
- Manage article drafts and submissions
permissions.ts:253-258):
Médiateur (Mediator)
Description: Facilitators of conflict resolution between parties Capabilities:- Conduct mediation sessions
- Sign mediation agreements
- Manage assigned mediation cases
permissions.ts:259-262):
Éducateur (Educator)
Description: Content creators for educational modules Capabilities:- Create and update educational modules
- Manage course content and lessons
- Track student progress
permissions.ts:263-266):
Modérateur (Moderator)
Description: Content moderators with oversight of community contributions Capabilities:- Access moderation queue
- Take moderation actions (approve, hide, delete)
- Delete any user-generated content (reviews, comments, forum posts, classifieds)
- Pin and lock forum threads
- Manage community standards enforcement
permissions.ts:267-280):
Administrateur (Administrator)
Description: Platform administrators with full system access Capabilities:- User management (create, delete, impersonate)
- Role assignment and management
- Organization administration
- Taxonomy management (categories, attributes, tags)
- Content approval and moderation
- Access audit logs and analytics
- Publish transparency reports
- System configuration
permissions.ts:281-329):
Permission Model
RBAC Matrix
Permissions are defined in a role-based matrix (appRbacMatrix) where each role has a set of allowed permissions. The system checks if any of the user’s roles grants the requested permission.
Permission Check Function
ABAC (Attribute-Based Access Control)
Some permissions require contextual validation beyond role membership:Ownership Checks
Ownership Checks
Permissions ending in
_own require that the user owns the resource:Admin Access Restrictions
Admin Access Restrictions
Admin access is restricted by time and IP address:
Privilege Escalation Prevention
Privilege Escalation Prevention
Prevents users from assigning themselves admin role:
Self-Action Prevention
Self-Action Prevention
Prevents users from reviewing or booking their own places:
Permission Categories
Permissions are organized by domain:| Domain | Examples |
|---|---|
| Auth | create_user, delete_user, impersonate_user, admin_access |
| Places | place.create, place.read, place.update_own, place.approve |
| Articles | article.create, article.read, article.update_any |
| Reviews | review.create, review.update_own, review.delete_any |
| Forum | forum.create_thread, forum.create_post, forum.pin_thread |
| Classifieds | classified.create, classified.update_own, classified.approve |
| Events | event.create, event.update_own, event.delete_any |
| Messaging | message.send, message.read_own |
| Economy | wallet.read_own, wallet.credit, wallet.transfer |
| Moderation | moderation.queue, moderation.action |
| Admin | admin.users, admin.audit, admin.config |
Multi-Role System
Users can hold multiple roles simultaneously. For example:- A user can be both Citoyen (default) and Propriétaire (managing places)
- An Auteur can also be a Modérateur
- All roles accumulate permissions (union of all role permissions)
concordia-specs.md:256-276):
Best Practices
Always check permissions before actions
Use
hasPermission() or checkPermission() before allowing users to perform actions.Provide context for ownership checks
When checking
_own permissions, always pass the resourceOwnerId and userId in the context.Handle permission errors gracefully
Return appropriate HTTP status codes (401 for unauthenticated, 403 for unauthorized).