Общие роли CMS и уровни доступа

Изучили ли вы существующие решения, такие как RBAC ? Хотя такая система, скорее всего, была бы полным излишеством для конкретного ореха, который вы пытаетесь расколоть, она, по крайней мере, поможет повысить уверенность в том, что вы на правильном пути.

Кроме того, общие роли, которые я ожидал бы будет примерно таким:

Администратор - Полный контроль над системой, может просматривать журналы (как вы должны регистрировать все изменения ) и т. д. плюс ...

Издатель - Может размещать контент в реальном времени плюс ...

Автор - Может создавать контент

Однако то, как эти роли применяются в системе, становится непростым делом, поскольку у конкретного пользователя, вероятно, будут разные права на различные области / модули содержимого.

Администратор - может создавать пользователей + все ниже

Редактор - может редактировать сообщения других + все ниже

Автор - может писать сообщения, редактировать собственные сообщения

Для большинства приложений, поэтому я думаю, что это будет верно и для CMS, мои клиенты обычно предпочитают подход, ориентированный на права. Вот как это происходит:

1. Вы перечисляете основные действия. В вашей CMS это будет: создавать и редактировать контент; Удалить контент; Классифицируйте / категоризируйте контент; Проверить контент; Публиковать контент; Управление пользователями; И т. Д.
2. Вы определяете, какие действия разрешены или запрещены для каждого пользователя.

Чтобы немного улучшить ситуацию, вы можете создать несколько ролей (Редактор; Администратор), чтобы упростить создание типичных пользователей (путем предварительного заполнения формы, когда роль выбрана).

Я задал этот вопрос немного назад и получил следующий ответ.

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

Я бы не стал отказываться от мелкозернистой системы управления, которая у вас есть сейчас. Если у вас есть адаптируемый, сосредоточьтесь на том, чтобы скрыть сложность, предоставив упрощенный интерфейс (например, используйте шаблон фасада или шаблон адаптера). Преимущества заключаются в том, что вы предоставляете пользователям упрощенную версию (простые разрешения, такие как «администратор» может «удалить« сообщение »), сохраняя при этом мелкозернистые функции, если они вам понадобятся позже (например, более сложная обработка разрешений - разрешить удаление сообщений, когда это ваше собственное сообщение в категории X). Затем вы можете предоставить альтернативу упрощенной версии для этой необходимости в некоторых местах.

I have a custom CMS built on the Zend Framework that uses Zend's ACL to extends some basic roles (so you can deny resources specifically for additional users or allow others to access resources they normally couldn't). My basic roles go from CMS users all the way down to website "members" as follows (I just use one users table to store all my authentication).

Developer

Edit any content, edit layouts, settings, configuration. Use special tools that can call shell scripts and force cron jobs.

Admin

Edit any content, edit layouts, settings.

Author

Edit content.

Member

Can view the login screen, forgot password and bug report.

Now, Zend has a nice ACL implementation so you can easily extends your base ACL class and add new roles that extend from the basic roles. So I might make an "Admin" who has access to one of the Developer tools (e.g. purge or cache management) or lock an author to only be able to manage blogs (and not for example news).

Администратор : Тот, у кого есть все права

Автор : Тот, кто имеет все права на определенный контент (например, автор блога, которому принадлежит блог), также имеет права добавлять / приглашать пользователей для совместной работы / просмотра контента

Сотрудник : тот, кто может редактировать / добавлять контент, на который автор предоставил права, не может удалять контент или приглашать / добавлять других соавторов

Средство просмотра : тот, кто может просматривать контент, если автор пригласил его для просмотра

Редакторы : тот, кто может утверждать / редактировать все типы контента

. плохая идея, если вы ожидаете, что продвинутые пользователи / разработчики будут использовать CMS. Но для начинающих менеджеров CMS основные роли делают систему намного более удобной.