CAPÍTULO 5 · Ver un botón no concede permiso
El botón desapareció, pero la dirección sigue existiendo
Ocultar un botón mejora la experiencia porque evita ofrecer una acción que el usuario no puede realizar. Pero el endpoint al que llamaba ese botón continúa en el servidor. Basta imaginar una solicitud enviada fuera de la página para reconocer que la protección todavía está incompleta si solo cambiamos el HTML.
Llevamos la política al backend. En las páginas Django podemos componer controles mediante mixins cuando la identidad ya está disponible; en DRF utilizamos su ciclo de permisos. También limitamos los objetos que cada actor puede alcanzar. Estar autenticado no significa poder modificar cualquier registro cuyo identificador se conozca.
Probamos la petición directa, además de observar la pantalla. La interfaz y la API quedan conectadas por una política común, cada una con su responsabilidad. Ahora aparece la pregunta anterior a todo permiso: de dónde proviene esa identidad y cómo podemos confiar en ella cuando las personas pertenecen a una organización que ya administra sus cuentas.
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
La puerta real está en el servidor
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Interfaz. Muestra acciones permitidas
- Petición. Puede fabricarse fuera de la UI
- API. Verifica identidad y permiso
- Objeto. Comprueba alcance de negocio
01 / EL PROBLEMA
¿Para qué sirve?
Ocultar el botón Configurar mejora la experiencia, pero el usuario puede llamar la API directamente. La decisión real debe ejecutarse en el backend.
02 / COMPRENDER
El concepto, explicado
Un context processor puede exponer flags derivados de capacidades. json_script pasa datos al navegador sin concatenar JSON inseguro en JavaScript.
DRF BasePermission adapta la política al ciclo HTTP. El permiso se verifica antes del handler; para acceso por estación, filtra el queryset y verifica objetos.
Para una página Django, un mixin puede comprobar autenticación y capacidad en dispatch, siempre que el middleware de identidad ya haya establecido request.user. Para una API de DRF, usa permission_classes y check_permissions: su autenticación se ejecuta dentro del ciclo de APIView, por lo que copiar un control de dispatch anterior a ese ciclo puede evaluar una identidad equivocada.
Un mixin no autentica por el hecho de existir. La autenticación identifica al usuario; la política autoriza la acción; el filtro por objeto limita qué registros puede alcanzar. Probar solo el botón visible deja estas tres garantías sin comprobar.
03 / CONSTRUIR
Implementación paso a paso
- Expón can_configure como flag.
- Oculta acciones que no están permitidas.
- Declara BasePermission en el endpoint.
- Prueba la URL directamente con un rol insuficiente.
04 / APLICAR
Ejemplo en SensorHub
# cuentas/permissions.py
from rest_framework.permissions import BasePermission
from .policy import can_configure
class CanConfigure(BasePermission):
def has_permission(self, request, view):
return can_configure(request.user)
# En un Command del ejemplo:
# permission_classes = [IsAuthenticated, CanConfigure]
# En el template:
# {{ capabilities|json_script:"page-capabilities" }}Cómo leer el ejemplo
- has_permission controla capacidad de entrada al endpoint.
- El template refleja la política, pero sus flags se pueden alterar en DevTools.
- has_object_permission necesita una implementación concreta y comprobación en vistas custom.
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
No confíes en role o can_configure enviado en el payload. Esos campos son controlados por el cliente.
05 / PRACTICAR
Tu turno
Cambia el flag de frontend y envía una solicitud como operador.
Ver solución orientativa
Aunque el botón se muestre, el servidor devuelve denegación porque CanConfigure consulta la identidad real y la política.
06 / VERIFICAR
Cómo sabes que funciona
- Una llamada directa no evita permisos.
- Las listas excluyen objetos fuera del alcance del usuario.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Identidad externa y MSAL →Continuar en modo relato