Skip to main content

​
Overview

The Church Management System implements a role-based access control (RBAC) system with two primary roles: Pastor and Member. Each role has specific permissions that determine what actions users can perform within the system.

​
User Roles

​
Pastor

Pastors have administrative privileges and can manage church operations, including:
  • Creating and managing churches
  • Managing church members
  • Creating and managing donation campaigns
  • Viewing all church statistics and reports
  • Inviting new members to the church

​
Member

Members have limited access focused on participation:
  • Viewing church information
  • Participating in donation campaigns
  • Viewing their own donation history
  • Updating their own profile
The role is assigned during user registration and cannot be changed after account creation.

​
Authentication Schema

The authentication system stores user credentials and role information: 
{
  email: {
    type: String,
    required: true,
    unique: true,
    lowercase: true,
    match: /^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$/
  },
  password: {
    type: String,
    required: true,
    minlength: 6
  },
  role: {
    type: String,
    required: true,
    enum: ['pastor', 'member']
  },
  invitedBy: {
    type: String,
    lowercase: true,
    match: /^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$/
  },
  isProfileComplete: {
    type: Boolean,
    default: false
  }
}
See the full schema in authprofilemodel.js:3-37

​
Role Enforcement

Role-based access control is enforced through middleware that validates the user’s role before allowing access to protected routes.

​
Authorization Middleware

The system uses the authorizeRoles middleware to restrict access: 
const authorizeRoles = (theTokenRole) => {
  return (req, res, next) => {
    if(theTokenRole == req.theUser.role){
      next();
    }
    else{
      res.status(403).send({
        success: false,
        message: 'Access Denied',
        data: `The role '${req.theUser.role}' is not allowed for this route`
      });
    }
  }
}
See implementation in rolemidddleware.js:1-14

​
Role-Based Endpoints

  • POST /api/churches - Create a new church
  • PUT /api/churches/:id - Update church information
  • DELETE /api/churches/:id - Delete a church
  • POST /api/donations - Create donation campaigns
  • PUT /api/donations/:id - Update donation campaigns
  • DELETE /api/donations/:id - Delete donation campaigns
  • POST /api/churches/:id/members - Add members to church
  • DELETE /api/churches/:id/members/:memberId - Remove members
  • GET /api/churches - View churches
  • GET /api/churches/:id - View church details
  • GET /api/donations - View donation campaigns
  • GET /api/donations/:id - View donation details
  • POST /api/donations/:id/donate - Make a donation
  • GET /api/profile - View own profile
  • PUT /api/profile - Update own profile

​
Invitation System

The system tracks user invitations through the invitedBy field:
When a pastor invites a new member, the invitedBy field stores the inviter’s email address for tracking and accountability.
{
  "email": "[email protected]",
  "role": "member",
  "invitedBy": "[email protected]",
  "isProfileComplete": false
}

​
Profile Completion

New users must complete their profile after registration:
  • The isProfileComplete flag tracks profile status
  • Defaults to false on registration
  • Set to true after users provide required profile information
  • Incomplete profiles may have restricted access to certain features
Users with incomplete profiles should be prompted to complete their profile information before accessing full system features.

​
Best Practices

  1. Always validate roles on the backend - Never rely solely on client-side role checks
  2. Use the middleware - Apply authorizeRoles middleware to all protected routes
  3. Log authorization failures - Track failed authorization attempts for security auditing
  4. Handle 403 errors gracefully - Provide clear feedback when users lack permissions

Build docs developers (and LLMs) love

Get started for freeTalk to us