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

В настоящее время я пишу CMS и помню, что кто-то (возможно, был здесь) критиковал существующую CMS за то, что у вас недостаточно надежная система разрешений пользователей. У меня есть метод, который планировался, но я чувствую, что он попал в обычную ловушку того, чтобы быть слишком тонким, что делает понимание и реализацию этого ужаса для конечных пользователей.

Я думаю, что для меня был бы задан ряд пользовательских ролей по умолчанию с разрешениями, поэтому я предполагаю, что мой вопрос таков:

Каковы роли по умолчанию, которые вы хотели бы видеть в CMS и какие разрешения были бы связаны с ними?

Спасибо заранее!

Ответ 1

Это "лучшая практика", с которой я столкнулся в большинстве проектов, и очень доволен:

1. Роли

Когда речь идет о ролях, я рекомендую большую гибкость, то есть способность создавать и определять учетные записи пользователей и группы свободно (такие роли, как "contributor", "manager" и т.д., не жестко закодированы, а помещаются в файл конфигурации, который можно изменить для каждого приложения). Конфигурация роли недоступна для пользователя, но сам движок должен быть свободен от жестко закодированных ролей.

2. Права

Права - это то, что должно быть легко понять и реализовать.

У меня очень хорошие впечатления, работающие с очень тонкими правами на уровне кода /API :

см
вид
изменить
изменить имя
переименуйте
удалить
шаг
изменить права
и др.

но пользователь никогда не видит эти. Для них они сгруппированы в очень небольшое число "правых групп":

Только для чтения
Изменить
Администрирование = Перемещение, переименование....

Пользователь никогда не видит права "двигаться", а только группу прав "Администрирование".

Таким образом, вы сохраняете полную силу мелкозернистых прав в своем коде в будущем - вы можете, например, легко вписаться в правило вроде "стажеры должны иметь возможность редактировать страницы, но не смогут изменять их названия или удалять их", добавив ценный актив в CMS. Для конечного пользователя эта функция остается невидимой, а система прав проста в использовании.

Ответ 2

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

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

Ответ 3

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

В стороне, общие роли, которые я ожидал бы, были бы следующими:

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

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

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

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

Ответ 4

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

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

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

Ответ 5

У меня есть пользовательская CMS, основанная на Zend Framework, которая использует Zend ACL для расширения некоторых основных ролей (поэтому вы можете отказывать в ресурсах специально для дополнительных пользователей или разрешать другим доступ к ресурсам, которые они обычно не могут). Мои основные роли идут от пользователей CMS вплоть до "членов" веб-сайта следующим образом (я просто использую одну таблицу пользователей для хранения всей моей аутентификации).

Разработчик

Отредактируйте любой контент, отредактируйте макеты, настройки, конфигурацию. Используйте специальные инструменты, которые могут вызывать скрипты оболочки и принудительно выполнять задания cron.

Администратор

Отредактируйте любой контент, отредактируйте макеты, настройки.

Автор

Изменить содержимое.

Член

Можно просмотреть экран входа в систему, забыли пароль и сообщить об ошибке.

Теперь у Zend есть хорошая реализация ACL, поэтому вы можете легко расширить свой базовый класс ACL и добавить новые роли, которые простираются от основных ролей. Поэтому я могу создать "Администратор", у которого есть доступ к одному из инструментов разработчика (например, очистка или управление кешем) или блокировать автора, чтобы иметь возможность управлять блогами (а не, например, новостями).

Ответ 6

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

Ответ 7

Admin: тот, у кого есть права

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

Collaborator. Тот, кто может редактировать/добавлять контент, которому автор предоставил права, не может удалить контент или пригласить/добавить больше соавторов.

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

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

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

Ответ 8

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

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

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

Ответ 9

Создатель - ответственен за создание и редактирование контента.

Редактор - отвечает за настройку содержимого сообщения и стиль доставки, включая перевод и локализация.

Издатель - ответственный за выпуск контента для использовать.

Администратор - ответственный за управление доступом разрешений для папок и файлов, обычно выполняемых путем назначения прав доступа к группам пользователей или ролям.

Потребитель, зритель или гость - человек, который читает или в противном случае принимает содержание после публикации или общий.