Ayuda de CDN.com.tr

Roles de equipo: viewer, editor y owner

Dé a cada colega su propio inicio de sesión y el rol más pequeño que le permita hacer su trabajo. El mismo rol se aplica en la API, así que un token bearer nunca puede hacer más que la persona a la que pertenece.

Organización, permisos, soporte

Roles de equipo: viewer, editor y owner

Para qué sirven los roles

Los roles y el registro de actividad son la misma funcionalidad vista desde dos lados: uno limita lo que puede pasar, el otro registra lo que pasó.

El registro

Activity history

Quién cambió qué, con valores anterior y posterior — legible solo porque cada persona tiene su propio inicio de sesión.

Abrir el tema

La página en sí

Sub-users and permissions

Crear, actualizar y desactivar los usuarios a los que se asignan estos roles.

Abrir el tema

Contexto

CDN activity log and team roles

Mínimo privilegio y un rastro de auditoría como un solo requisito, y cómo responderlo en una licitación.

Leer la guía

Ruta en el panel

Management Panel
Authorization
Create New User
Role

Requisitos previos

Solo el owner de la cuenta puede crear sub-usuarios y fijar roles.
Cada persona necesita su propia dirección de correo; el rastro de auditoría no vale nada si dos personas comparten una.
Decida el rol antes de crear el usuario — es más fácil que explicar después un vacío de permisos.

Modelo de decisión

¿Qué rol necesita esta persona?

Elija según lo mínimo que la desbloquee, no según su antigüedad.

Viewer: reportes, monitoreo, una agencia que solo lee números de consumo y caché.
Editor: el desarrollador o publicador que purga después de un deploy, edita delivery rules y gestiona DNS y certificados.
Owner: usted, y cualquiera en quien confiaría con la facturación y con agregar otros usuarios.

¿Un inicio de sesión o uno por persona?

Esta decisión determina si el registro de auditoría puede responder alguna vez una pregunta.

Un inicio de sesión por persona: cada fila en Activity history nombra a una persona real.
Un inicio de sesión compartido: cada acción se ve idéntica, y quitar a una persona significa cambiar la contraseña para todos.

Guía paso a paso

Cree el usuario

Authorization es la página que gestiona los sub-usuarios de todo el cliente, no por cuenta.

Abra Authorization y haga clic en Create New User.
Complete nombre, apellido, correo, teléfono y la contraseña dos veces.
No envíe todavía — la lista de roles está al final del mismo formulario.

Resultado esperado: El formulario de usuario nuevo está completo y la tabla de roles es visible debajo de los campos de contraseña.

cdnctl equivalent

POST /api/subusers

Fije el rol

La tabla de roles lista los roles con un interruptor inactivo/activo en cada uno. Active el que la persona necesita.

Active Viewer (read-only) para alguien que solo lee reportes.
Active Editor para alguien que purga, o edita delivery rules, DNS o certificados.
Deje todo desactivado solo si quiere un viewer — eso es a lo que cae un rol vacío.
Haga clic en Create User.

Resultado esperado: El usuario se crea exactamente con el rol elegido, y puede iniciar sesión con sus propias credenciales.

cdnctl equivalent

GET /api/roles

Confirme que el límite se mantiene

Verifique desde la cuenta nueva, no desde la suya. Es una comprobación de dos minutos que evita una mala sorpresa.

Haga que la persona inicie sesión y abra las páginas que necesita.
Pida a un viewer que intente guardar algo y confirme que se le rechaza.
Abra Activity history y confirme que sus acciones quedan registradas bajo su propio nombre.

Resultado esperado: La persona puede hacer su trabajo, está bloqueada de todo lo demás, y toda acción que realiza es atribuible.

cdnctl equivalent

GET /api/accounts/<account_uuid>/activities?per_page=25

Verificación

Un viewer puede abrir todas las páginas pero no puede guardar nada excepto su propio perfil y contraseña.
Un editor puede purgar y editar delivery rules pero no tiene acciones de sub-usuarios ni de facturación.
Un token emitido a un sub-usuario es rechazado en los endpoints que su rol no cubre.
Activity history nombra al sub-usuario, no al owner, después de que hace un cambio.

Casos de uso

Dos o tres personas trabajan en la misma cuenta de CDN: una publica y necesita purgar, otra solo lee los reportes, y solo usted debería poder agregar usuarios o tocar la facturación. Una contraseña compartida da a las tres el mismo poder y vuelve inútil el registro de auditoría.

Flujo de trabajo rápido

Abra Authorization y cree un usuario para cada persona en lugar de compartir un inicio de sesión.
Fije el rol en el usuario nuevo: viewer para solo lectura, editor para operaciones del día a día, owner para control total.
Haga que la persona inicie sesión y confirme que puede hacer su trabajo y nada más allá de eso.
Revise Activity history después: sus acciones ahora aparecen bajo su propio nombre.

Verificaciones

Viewer: lee todas las páginas, y puede cambiar su propio perfil y contraseña. Ninguna otra escritura.
Editor: purga, delivery rules, DNS, certificados y hostnames. Sin gestión de sub-usuarios, sin facturación, sin eliminación de cuenta.
Owner: todo, incluidos usuarios y facturación. Este es el rol con el que se registró la cuenta.
Dejar el rol vacío convierte al usuario en viewer. Un usuario nuevo nunca se crea con más poder del que usted otorgó.
La API aplica las mismas reglas. Un token de viewer no puede escribir, y un token de editor es rechazado en endpoints exclusivos de owner.