Enhancement: Implement Role-Based Authorization (RBAC)

[Bhoomi070]

🚀 Objective

Implement Role-Based Authorization (RBAC) to introduce permission control between different user types (e.g., admin, user).
Currently, all authenticated users have equal permissions. This enhancement will improve security and moderation control.

🛠 Tasks

1. Add a role field in the User schema:
   Type: String
   Enum: ['user', 'admin']
   Default: 'user'

2. Include role in the JWT access token payload.

3. Create an authorizeRoles middleware that: Accepts allowed roles as parameters
   Restricts access if the user’s role is not permitted

4. Apply role restrictions:

   Admin can delete/update any video or comment
   Users can only modify/delete their own content

✅ Acceptance Criteria

-Role field is properly added and stored in the database
-JWT payload includes user role
-Middleware correctly restricts unauthorized access
-Unauthorized requests return HTTP 403
-Existing functionality remains unaffected

🧪 Testing Instructions

1. Create one admin user and one regular user
2. Verify:
   • Admin can delete/update any content
   • Regular user cannot modify other users’ content

[Sanjay24-05]

Hi @Bhoomi070 i would like to work on this issue

[himadri75]

HI @Bhoomi070 I would like to work on this issue. I have experience in managing authorization and security.

[navin-oss]

Hi @Bhoomi070,
I’d like to work on this RBAC enhancement.
Plan:
• Add role field to the User schema (enum: user/admin)
• Include role in JWT payload
• Implement reusable authorizeRoles(...roles) middleware
• Protect routes for admin-only actions and ownership-based checks
• Add tests to verify 403 responses and ensure existing flows remain unaffected
If this approach looks good, please assign the issue to me. I can start right away.
Thanks!

[Bhoomi070]

Hi @navin-oss ,
Thanks for taking this up your plan looks well structured 👍

While implementing, please ensure:

The authorizeRoles(...roles) middleware remains reusable and clean
Ownership checks are handled separately from role-based checks
Existing authentication flows are not broken
Unauthorized requests return proper 403 responses with meaningful messages

Looking forward to your implementation .

[navin-oss]

Hi @Bhoomi070,

Thank you for the guidance. I’ve completed the implementation while keeping your points in mind:

• authorizeRoles(...roles) is implemented as a clean, reusable middleware focused strictly on role validation.
• Ownership checks are handled separately to maintain clear separation of concerns.
• Existing authentication flow remains unchanged and fully functional.
• All unauthorized access attempts return proper 403 responses with clear and meaningful messages.

Unit tests have been added to verify role restrictions and ownership behavior.

Please review when convenient.

[vallabhatech]

hey @Sohaibkundi2 can you assigin me ?