Permisos por rol en Digital Signage (s121)

Descripción

A partir de la sesión 121 (2026-06-09), el módulo Digital Signage (cartelería digital) aplica control de acceso basado en roles como el resto de CreaRack-Pro. Hasta ahora cualquier usuario autenticado en la organización —incluidos usuarios de solo lectura— podían hacer de todo: subir y borrar contenido, crear/editar/borrar playlists y pantallas, generar enlaces públicos para clientes externos, aprobar cambios e incluso disparar despliegues a dispositivos.

Con esta feature, el permiso de edición es obligatorio para cualquier mutación (create/update/delete/deploy/approve); las lecturas sensibles (reportes, auditoría, sincronización) exigen al menos permiso de vista.

Impacto

Antes:

readonly user → sube media, borra playlists, aprueba cambios, inicia deploy

Después:

readonly user → ve datos; NO puede mutar
operator user → puede editar contenido, listas, cronogramas, despliegues
admin user → acceso total

Cambios técnicos

1. Scope signage registrado en core/utils/permissions.py

VALID_SCOPES = (
    # ...
    "signage",  # NUEVO
)

ROLE_DEFAULTS = {
    "admin": { "signage": "edit", ... },
    "operator": { "signage": "edit", ... },
    "readonly": { "signage": "view", ... },
}

2. Gates en endpoints internos (signage/api/*)

Todas las mutaciones de content, playlists, players, schedules, share_links, approvals, deployments, display_control:

• require_perm(signage, edit) antes de create/update/delete/deploy/approve.

Todas las lecturas sensibles (reportes hondos, datos SNMP, datos de sincronización):

• require_perm(signage, view) antes de ejecutar.

Ejemplos (de CHANGELOG.md):

• upload_media: require_perm(signage, edit) al inicio.
• bulk_delete_media: require_perm(signage, edit).
• create_deployment: require_perm(signage, edit).
• deploy_content_to_device: require_perm(signage, edit).
• update_corporate_image: require_perm(signage, edit).
• Listados de reportes: require_perm(signage, view).

3. Validación de scope en aprobaciones (M4)

Cuando un usuario aprueba un cambio solicitado por un cliente externo vía el portal (ClientShareLink), la nueva lógica valida que el playlist_id/schedule_id sigue dentro del scope permitido del share link — no solo que pertenezca a la org. El scope pudo cambiar entre la solicitud y la aprobación.

4. IDOR potencial en create_deployment (M8)

Ahora rechaza con código 400 (Bad Request) si un playlist_id o schedule_id no pertenece a la organización del usuario.

Seguridad multi-tenant

Cierra un agujero de seguridad real descubierto en la Auditoría Suprema del dominio signage:

1. Privacidad: un readonly no puede ver/modificar contenido más allá de su rol.
2. Integridad: solo un operador autorizado puede cambiar lo que se muestra en las pantallas públicas.
3. Cumplimiento: alineado con el modelo de permisos estándar de CreaRack (como en network/racks/monitoring).

Archivos tocados

• core/utils/permissions.py — registro del scope
• signage/api/content.py — gates en upload/delete/transcode/reprocess
• signage/api/playlists.py — gates en CRUD
• signage/api/players.py — gates en CRUD
• signage/api/schedules.py — gates en CRUD
• signage/api/share_links.py — gates en CRUD
• signage/api/approvals.py — gates en aprobación + revalidación de scope
• signage/api/deployments.py — gates + validación IDOR
• signage/api/display_control.py — gates en control remoto
• monitoring/api/signage/deploy.py — gates en deploy/restore/publish
• monitoring/api/signage/dashboard.py — gates en dashboard/reportes
• monitoring/api/signage/discovery.py, groups.py, summary.py — gates en consultas

Véase también

• [[decision—20260609—signage-broken-access-control]]
• [[concept—saas—multi-tenancy]]
• [[concept—core—role-based-access-control]]
• [[entity—core—permission-system]]
• [[incident—audit-suprema-signage]]