Skip to main content

​
Overview

The Sistema de Permisos Municipales implements role-based access control (RBAC) with three distinct user roles. Each role has specific permissions that determine what actions users can perform.

​
User roles

Desarrollador

Highest privilegesFull system access including all administrative functions and user management.

Administrador

Administrative accessCan manage users and permits but cannot modify other administrators or developers.

Analista

Standard accessCan create, view, and manage permits but cannot access user management.

​
Role capabilities

​
Desarrollador (Developer)

Full system access with no restrictions:
  • Create all types of users (Desarrollador, Administrador, Analista)
  • Edit all user accounts
  • Delete any user account
  • View all users
  • Change any user’s role
  • Create permits
  • Edit permits
  • Approve permits
  • Cancel permits
  • Delete permits
  • Generate reports
  • Export PDFs
  • Access all routes and endpoints
  • View system configuration
  • Access administrative interfaces
  • Full database access

​
Administrador (Administrator)

Administrative access with some restrictions:
✅ Can:
  • Create Administrador and Analista users
  • Edit Administrador and Analista accounts (except Desarrollador accounts)
  • Delete Administrador and Analista accounts
  • View all users
❌ Cannot:
  • Create Desarrollador accounts
  • Edit Desarrollador accounts
  • Delete Desarrollador accounts
  • Edit their own account
  • Full permit management capabilities (same as Desarrollador)
  • Create, edit, approve, cancel permits
  • Delete permits
  • Generate reports
  • Access administrative interfaces
  • View configuration (but cannot modify system settings)

​
Analista (Analyst)

Standard operational access:
  • Create permits
  • Edit own permits (before approval)
  • View all permits
  • Search and filter permits
  • Export approved permits as PDF
  • Generate reports
❌ Cannot:
  • Approve permits (requires Administrador/Desarrollador)
  • Delete permits
  • Access user management
  • Access administrative settings
  • Edit other users’ information

​
Role verification

The system uses middleware to enforce role-based access:

​
verifySession middleware

Checks if a user is authenticated: 
// src/middlewares/verifySession.js
module.exports = (req, res, next) => {
  if('usuario' in req.session){
    next();
  } else {
    res.redirect('http://' + req.headers.host);
  }
};

​
verifyRoles middleware

Restricts access to specific roles: 
// src/middlewares/verifyRoles.js
module.exports = (...roles) => {
  return (req, res, next) => {
    if('usuario' in req.session){
      if(roles.includes(req.session.usuario.tipo_usuario)){
        next();
      } else {
        res.status(403).json({message: 'Acceso denegado'});
      }
    } else {
      res.redirect('http://' + req.headers.host);
    }
  };
};

​
Usage example

// Restrict delete endpoint to Administrador and Desarrollador
router.delete('/', 
  verifySession, 
  verifyRoles('Administrador', 'Desarrollador'), 
  upload.none(), 
  async (req, res) => {
    // Delete logic
  }
);

​
Protected routes

​
User management routes

​
GET /usuarios
endpoint
Required role: Administrador or DesarrolladorList all users in the system.
​
POST /usuarios/add
endpoint
Required role: Administrador or DesarrolladorCreate a new user account.
​
GET /usuarios/edit/:username
endpoint
Required role: Administrador or DesarrolladorEdit restrictions:
  • Cannot edit own account
  • Administrador cannot edit Desarrollador accounts
​
POST /usuarios/delete
endpoint
Required role: Administrador or DesarrolladorDelete restrictions apply (same as edit).

​
Permit deletion routes

​
DELETE /venta_de_bebidas
endpoint
Required role: Administrador or DesarrolladorDelete beverage permits with validation.
​
DELETE /publicidad_y_propaganda
endpoint
Required role: Administrador or DesarrolladorDelete advertising permits with validation.
​
DELETE /eventos_especiales
endpoint
Required role: Administrador or DesarrolladorDelete event permits with validation.

​
Access control logic

​
User account editing

The system prevents users from editing their own accounts or higher-privileged accounts: 
// From src/routes/usuarios.js
if(req.session.usuario.indicador == result[0].username || 
   result[0].tipo_usuario == 'Desarrollador'){
  res.redirect('http://' + req.headers.host + '/usuarios');
}
This prevents:
  • Self-editing (could change own role to Desarrollador)
  • Administrators editing Desarrollador accounts

​
Route protection patterns

Pattern 1: Session only 
if('usuario' in req.session){
  // Allow access
} else {
  res.redirect('http://' + req.headers.host);
}
Pattern 2: Session + role check 
if(('usuario' in req.session) && 
   (req.session.usuario.tipo_usuario == 'Desarrollador' || 
    req.session.usuario.tipo_usuario == 'Administrador')){
  // Allow access
} else {
  res.redirect('http://' + req.headers.host);
}
Pattern 3: Middleware-based 
router.delete('/', 
  verifySession, 
  verifyRoles('Administrador', 'Desarrollador'),
  handler
);

​
Permission matrix

ActionAnalistaAdministradorDesarrollador
Authentication
Login✅✅✅
Change own password✅✅✅
Logout✅✅✅
Permit Operations
View permits✅✅✅
Create permits✅✅✅
Edit permits✅✅✅
Search permits✅✅✅
Approve permits❌✅✅
Cancel permits❌✅✅
Delete permits❌✅✅
Generate PDFs✅✅✅
Generate reports✅✅✅
User Management
View users❌✅✅
Create Analista❌✅✅
Create Administrador❌✅✅
Create Desarrollador❌❌✅
Edit Analista❌✅✅
Edit Administrador❌✅✅
Edit Desarrollador❌❌✅
Delete users❌✅✅
Edit own account❌❌❌

​
Session storage

User role information is stored in the session: 
req.session.usuario = {
  indicador: result[0].username,     // Username
  nombre: result[0].nombre,          // First name
  apellido: result[0].apellido,      // Last name
  cargo: result[0].cargo,            // Position
  tipo_usuario: result[0].tipo_usuario // Role (key for permissions)
};
The tipo_usuario field determines the user’s capabilities throughout the application.

​
Best practices

Principle of least privilege

Assign users the minimum role needed for their job functions. Most users should be Analistas.

Regular audits

Periodically review user roles and remove unnecessary elevated privileges.

Desarrollador protection

Limit the number of Desarrollador accounts. They have unrestricted system access.

Role changes

Document why users receive elevated privileges (Administrador or Desarrollador).

​
Security considerations

Important security notes:
  1. Cannot self-elevate: Users cannot edit their own accounts to gain higher privileges
  2. Desarrollador protection: Only other Desarrolladores can modify Desarrollador accounts
  3. Role validation: User roles are validated on every protected request
  4. Session-based: All role checks depend on valid session data
If you need to add a new role or modify permissions, you’ll need to:
  1. Update the database schema to include the new role
  2. Modify validation rules in src/routes/usuarios.js
  3. Update middleware role checks
  4. Update the UI to show/hide features based on role

​
Next steps

User management

Learn how to create and manage users

Authentication

Understand the authentication system

Build docs developers (and LLMs) love

Get started for freeTalk to us