php - tag - Funciones comunes de CMS y niveles de acceso

tooltip title html (9)

¿Has investigado soluciones existentes como RBAC ? Si bien es probable que un sistema de este tipo sea una exageración total para la tuerca particular que intenta romper, al menos ayudaría a aumentar la confianza en que está en el camino correcto.

Aparte de eso, los roles generales que esperaría estarían en la línea de:

Administrador : el control total del sistema, puede ver los registros (como debería estar registrando todos los cambios ), etc. más ...

Editor - Puede poner contenido en vivo más ...

Autor - Puede crear contenido

Sin embargo, la forma en que estos roles se aplican en todo el sistema es donde las cosas se complican, ya que un usuario específico probablemente tendrá diferentes derechos para diferentes áreas / módulos de contenido.

Actualmente estoy escribiendo un CMS y recuerdo que alguien (podría haber estado aquí) critica al CMS existente por no tener un sistema de permisos de usuario lo suficientemente robusto. Tengo un método planificado, pero creo que ha caído en la trampa habitual de ser un poco demasiado fino, lo que hace que entenderlo e implementarlo sea un horror para los usuarios finales.

Creo que tener un rango de roles de usuario predeterminados con permisos sería la respuesta a esto, así que supongo que mi pregunta es la siguiente:

¿Cuáles son los roles predeterminados que le gustaría ver en un CMS y qué tipo de permisos estarían asociados con estos?

¡Gracias por adelantado!

Administrador - puede crear usuarios + todos a continuación

Editor - puede editar mensajes de otros + todos abajo

Autor - puede escribir publicaciones, editar publicaciones propias

Esta es la "mejor práctica" que terminé en la mayoría de los proyectos y estoy muy feliz con:

1. roles

Cuando se trata de roles, recomiendo una gran flexibilidad, es decir, la capacidad de crear y definir cuentas de usuarios y grupos libremente (los roles como "contribuyente", "administrador", etc. no están codificados, pero se colocan en un archivo de configuración que puede ser cambiado por aplicación) . La configuración de la función es inaccesible para el usuario, pero el motor en sí debe estar libre de funciones codificadas.

2. derechos

Los derechos es donde las cosas deben ser fáciles de entender e implementar .

He tenido muy buenas experiencias trabajando con, y comprobando, derechos muy específicos en el nivel de código / API :

ver
ver
editar
cambiar nombre
rebautizar
borrar
movimiento
cambiar derechos
etc.

pero el usuario nunca ve esos . Para ellos, se agrupan en un número muy pequeño de "grupos correctos":

Solo lectura
Editar
Administrar = Mover, renombrar ....

El usuario nunca ve el "movimiento" a la derecha, sino solo el grupo de derechos "Administrar".

De esa manera, conservará todo el poder de los derechos específicos en su código para el futuro; por ejemplo, puede adaptarse fácilmente a una regla como "los internos deben poder editar páginas, pero no pueden cambiar sus títulos, ni eliminarlos ", añadiendo un activo valioso al CMS. Para el usuario final, esta funcionalidad permanece invisible y el sistema de derechos es fácil de usar.

Hice esta pregunta hace poco y obtuve la siguiente respuesta.

admin //Manage everything manager //Manage most aspects of the site editor //Scheduling and managing content author //Write important content contributors //Authors with limited rights moderator //Moderate user content member //Special user access subscriber //Paying Average Joe user //Average Joe

No necesariamente descartaría el sistema de control de grano fino que tiene ahora. Si tiene un enfoque adaptable para ocultar la complejidad, proporcione una interfaz simplificada (por ejemplo, use el patrón de fachada o el patrón de adaptador). Los beneficios son que proporciona a los usuarios la versión simplificada (los permisos simples como ''admin'' pueden ''eliminar'' una ''publicación'') mientras se conservan las características detalladas si las necesita más adelante (por ejemplo, el manejo de permisos más complicado es permitir que se eliminen) Publicaciones cuando la publicación es su propia publicación en la categoría X). Luego, puede proporcionar una alternativa a la versión simplificada para esa necesidad en algunos lugares.

Para la mayoría de las aplicaciones, creo que también será cierto para los CMS, mis clientes generalmente prefieren un enfoque orientado a los derechos. Aquí es cómo va :

Enumeras las principales acciones. En tu CMS, eso sería: Crear y editar contenido; Eliminar contenido; Clasificar / clasificar contenido; Validar el contenido; Publicar contenido; Administrar usuarios; Etc.
Usted define qué acciones están permitidas o negadas para cada usuario.

Para mejorar un poco las cosas, puede crear varias funciones (Editor; Administrador) para facilitar la creación de usuarios típicos (rellenando el formulario antes de elegir una función).

Tengo un CMS personalizado construido en Zend Framework que usa la ACL de Zend para extender algunos roles básicos (para que pueda denegar recursos específicamente para usuarios adicionales o permitir que otros accedan a recursos que normalmente no podían). Mis funciones básicas van desde los usuarios de CMS hasta los "miembros" del sitio web de la siguiente manera (solo uso una tabla de usuarios para almacenar toda mi autenticación).

Desarrollador

Editar cualquier contenido, editar diseños, configuraciones, configuración. Use herramientas especiales que pueden llamar a scripts de shell y forzar trabajos de cron.

Administración

Editar cualquier contenido, editar diseños, configuraciones.

Autor

Contenido editado.

Miembro

Puede ver la pantalla de inicio de sesión, contraseña olvidada y el informe de errores.

Ahora, Zend tiene una buena implementación de ACL para que pueda ampliar fácilmente su clase de ACL base y agregar nuevos roles que se extiendan desde los roles básicos. Por lo tanto, podría crear un "administrador" que tenga acceso a una de las herramientas del desarrollador (por ejemplo, administración de purga o caché) o bloquear a un autor para que solo pueda administrar blogs (y no, por ejemplo, noticias).

Admin : El de todos los derechos.

Autor : el que tiene todos los derechos sobre un contenido específico (como el autor de un blog que posee el blog), también tiene los permisos para agregar / invitar a usuarios a colaborar / ver el contenido.

Colaborador : el que puede editar / agregar contenido para el cual el autor ha otorgado derechos, no puede eliminar el contenido o invitar / agregar más colaboradores

Visor : el que puede ver el contenido si el autor ha invitado a ver

Editores : el que puede aprobar / editar todo tipo de contenido

Tener un control de grano fino no es una mala idea si espera que los usuarios / desarrolladores avanzados utilicen el CMS. Pero para los administradores novatos de CMS, los roles básicos hacen que el sistema sea mucho más utilizable.

Creador - responsable de crear y editar contenido.

Editor : responsable de ajustar el mensaje de contenido y el estilo de entrega, incluida la traducción y la localización.

Editor - responsable de liberar el contenido para su uso.

Administrador : responsable de administrar los permisos de acceso a carpetas y archivos, generalmente se realiza mediante la asignación de derechos de acceso a grupos de usuarios o roles.

Consumidor, espectador o invitado : la persona que lee o toma contenido después de que se publica o comparte.