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

Question

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

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

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

Заранее спасибо!

Answer 1

Это «лучшая практика», которую я использовал в большинстве проектов, и я очень доволен:

1.Роли

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

2.Права

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

Я получил очень хороший опыт работы и проверки очень детальные права на уровне кода/API:

• видеть
• вид
• редактировать
• Сменить имя
• переименовывать
• удалить
• двигаться
• изменить права
• и т. д.

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

• Только чтение
• Редактировать
• Администрирование = Переместить, переименовать....

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

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

Answer 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

Answer 3

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

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

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

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

Автор - Умею создавать контент

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

Answer 4

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

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

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

Answer 5

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

Разработчик

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

Админ

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

Автор

Редактировать контент.

Член

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

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

Answer 6

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

Answer 7

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

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

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

Зритель :Тот, кто может просматривать контент, если автор пригласил на просмотр

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

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

Answer 8

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

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

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

Answer 9

Автор - отвечает за создание и редактирование контента.

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

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

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

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