CAPÍTULO 5 · Ver un botón no concede permiso
La misma plataforma, responsabilidades diferentes
SensorHub ya puede ofrecer un catálogo y recibir interacciones, pero sus usuarios no tienen necesariamente el mismo trabajo. Quien consulta una medición puede no estar autorizado para cambiar el umbral de una alarma. Si escribimos esas diferencias como condiciones sueltas en cada pantalla, la política dependerá de que todos recuerden exactamente la misma regla.
Definimos capacidades en un lugar central y relacionamos los roles con ellas. El código puede preguntar si una persona puede configurar, en lugar de repetir nombres de roles por todas partes. También establecemos qué sucede cuando la identidad o el rol no permiten tomar una decisión afirmativa: la capacidad no se concede por suposición.
Con esa política podemos adaptar la interfaz y evitar mostrar acciones que no corresponden. Sin embargo, el navegador no es una frontera confiable. Alguien puede modificarlo o llamar directamente a una URL. La misma decisión que ayuda a presentar un botón debe convertirse en una condición real para ejecutar la operación.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Una llave por capacidad
Las flechas muestran responsabilidades relacionadas; no representan un orden obligatorio de ejecución.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Actor. Identidad del ejemplo
- Política. Relaciona roles y capacidades
- Capacidad. Permite una acción específica
- Decisión. Autoriza o deniega con alcance
01 / EL PROBLEMA
¿Para qué sirve?
Comparar nombres de roles en cada vista produce reglas divergentes. Una capacidad expresa la intención que el negocio permite.
02 / COMPRENDER
El concepto, explicado
Autenticación responde quién actúa; autorización decide qué puede hacer. El rol agrupa capacidades y no debe ser el único lenguaje del código.
En SensorHub usaremos operador, supervisor y administrador. El operador consulta, el supervisor configura umbrales y el administrador también administra el catálogo. Un usuario sin rol no obtiene capacidad.
03 / CONSTRUIR
Implementación paso a paso
- Enumera acciones del negocio.
- Define una función central por capacidad.
- Trata anónimos y roles desconocidos como denegados.
- Reutiliza las funciones en adaptadores.
04 / APLICAR
Ejemplo en SensorHub
# cuentas/policy.py
from enum import StrEnum
class Role(StrEnum):
OPERATOR = "operator"
SUPERVISOR = "supervisor"
ADMIN = "admin"
def role_for(user):
if not getattr(user, "is_authenticated", False):
return None
value = getattr(getattr(user, "profile", None), "role", None)
try:
return Role(value)
except (ValueError, TypeError):
return None
def can_configure(user):
return role_for(user) in {Role.SUPERVISOR, Role.ADMIN}Cómo leer el ejemplo
- profile es una relación a crear en tu aplicación de ejemplo; no viene automáticamente con Django.
- La capacidad evita repetir conjuntos de roles en muchas superficies.
- La academia no usa esta política para restringir acceso: todos pueden estudiar.
EXPLORADOR DE CAPACIDADES
Qué cambia según el rol
Simulación didáctica: no autentica usuarios ni concede permisos en esta web.
| Capacidad | Operador | Supervisor | Administrador |
|---|---|---|---|
| Consultar mediciones | Sí | Sí | Sí |
| Configurar umbrales | No | Sí | Sí |
| Administrar catálogo | No | No | Sí |
Error habitual
Una capacidad global no restringe qué estación pertenece al usuario. Agrega alcance por objeto cuando el producto lo requiera.
05 / PRACTICAR
Tu turno
Define can_manage_catalog sin permitir al supervisor.
Ver solución orientativa
Retorna role_for(user) is Role.ADMIN; agrega pruebas para cada rol y usuario sin perfil.
06 / VERIFICAR
Cómo sabes que funciona
- Los roles desconocidos no elevan privilegios.
- Cambiar la política central modifica todos sus adaptadores.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Permisos de frontend y protección de API →Continuar en modo relato