В настоящее время я пишу CMS и помню, как кто-то (возможно, был здесь) критикует существующую CMS за то, что у вас недостаточно надежная система разрешений пользователей. У меня есть метод, который планировался, но я чувствую, что он попал в обычную ловушку того, чтобы быть слишком тонким, что делает понимание и реализацию этого ужаса для конечных пользователей.
Я думаю, что для меня был бы задан ряд пользовательских ролей по умолчанию с разрешениями, поэтому я предполагаю, что мой вопрос таков:
Каковы роли по умолчанию, которые вы хотели бы видеть в CMS и какие разрешения были бы связаны с ними?
Заранее спасибо!
Это «лучшая практика», с которой я столкнулся в большинстве проектов, и очень доволен:
1. Роли
Когда речь идет о ролях, я рекомендую большую гибкость, то есть способность создавать и определять учетные записи пользователей и группы свободно (такие роли, как «contributor», «manager» и т. Д., Не жестко закодированы, а помещаются в файл конфигурации, который может быть изменено для каждого приложения) . Конфигурация роли недоступна для пользователя, но сам движок должен быть свободен от жестко закодированных ролей.
2. Права
Права – это то, что вещи нужно легко понять и реализовать .
Я очень хорошо поработал с очень сложными правами на уровне кода / API :
но пользователь никогда их не видит . Для них они сгруппированы в очень небольшое число «правильных групп»:
Пользователь никогда не видит право «двигаться», а только группу прав «Администрирование».
Таким образом, вы сохраняете полную полноту прав в своем коде в будущем – например, вы можете легко приспособиться к правилу, например, «стажеры должны иметь возможность редактировать страницы, но не иметь возможности изменять свои названия, и не удалять их ", добавив ценный актив в CMS. Для конечного пользователя эта функциональность остается невидимой, а система прав проста в использовании.
Я задал этот вопрос немного назад и получил следующий ответ.
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 Вы исследовали существующие решения, такие как RBAC ? Хотя такая система, скорее всего, будет полным излишеством для конкретного ореха, который вы пытаетесь взломать, по крайней мере поможет повысить уверенность в том, что вы на правильном пути.
В общем, общие роли, которые я ожидал бы, были бы следующими:
Администратор – полный контроль над системой, просмотр журналов (как вы должны регистрировать все изменения ) и т. Д. Плюс …
Издатель – может разместить контент в прямом эфире плюс …
Автор – может создавать контент
Однако, как эти роли применяются во всей системе, ситуация становится сложной, поскольку конкретный пользователь, по-видимому, имеет разные права на разные области / модули контента.
Для большинства приложений, поэтому я думаю, что это будет верно и для CMS, мои клиенты обычно предпочитают подход, ориентированный на права. Вот как это происходит:
Чтобы сделать вещи немного лучше, вы можете создать несколько ролей (Editor; Administrator), чтобы упростить создание типичных пользователей (предварительно заполняя форму при выборе роли).
У меня есть пользовательская CMS, основанная на Zend Framework, которая использует ACL Zend для расширения некоторых основных ролей (чтобы вы могли отказывать в ресурсах специально для дополнительных пользователей или разрешать другим пользователям доступ к ресурсам, которые они обычно не могли). Мои основные роли идут от пользователей CMS вплоть до «членов» веб-сайта следующим образом (я просто использую одну таблицу пользователей для хранения всей моей аутентификации).
разработчик
Редактируйте любой контент, редактируйте макеты, настройки, настройки. Используйте специальные инструменты, которые могут вызывать сценарии оболочки и принудительно выполнять задания cron.
Администратор
Редактируйте любой контент, отредактируйте макеты, настройки.
автор
Редактировать содержимое.
член
Можно просмотреть экран входа в систему, забыли пароль и сообщить об ошибке.
Теперь у Zend есть хорошая реализация ACL, поэтому вы можете легко расширить свой базовый класс ACL и добавить новые роли, которые простираются от основных ролей. Поэтому я могу создать «Администратора», который имеет доступ к одному из инструментов разработчика (например, очистке или управлению кешем) или блокирует автора, чтобы иметь возможность управлять блогов (а не, например, новостями).
Я бы не стал отказываться от мелкозернистой системы управления, которой вы располагаете сейчас. Если у вас есть адаптируемый подход к утаиванию сложности, предоставляя упрощенный интерфейс (например, используйте шаблон фасада или шаблон адаптера). Преимущества заключаются в том, что вы предоставляете пользователям упрощенную версию (простые разрешения, такие как «admin», могут «удалять» сообщение «), сохраняя при этом мелкозернистые функции, если они вам понадобятся позже (например, более сложная обработка разрешений позволяет удалить сообщения, когда сообщение является вашим собственным сообщением в категории X). Затем вы можете предоставить альтернативу упрощенной версии для этой потребности в некоторых местах.
Admin : тот, у кого есть все права
Автор : Тот, кто имеет все права на определенный контент (например, автор блога, который владеет блогом), также имеет права добавлять / приглашать пользователей для совместной работы / просмотра содержимого
Коллаборатор : тот, кто может редактировать / добавлять контент, на который автор предоставил права, не может удалить контент или пригласить / добавить больше соавторов
Viewer : тот, кто может просматривать контент, если автор пригласил посмотреть
Редакторы : тот, кто может одобрять / редактировать все типы контента
Наличие мелкого контроля над зерном – неплохая идея, если вы ожидаете, что продвинутые пользователи / разработчики будут использовать CMS. Но для начинающих менеджеров CMS основные роли делают систему более удобной.
Администратор – может создавать пользователей + все ниже
Редактор – может редактировать сообщения других + все ниже
Автор – можете писать сообщения, редактировать собственные сообщения
Создатель – ответственный за создание и редактирование контента.
Редактор – отвечает за настройку содержимого сообщения и стиля доставки, включая перевод и локализацию.
Издатель – ответственный за выпуск контента для использования.
Администратор – ответственный за управление разрешениями доступа к папкам и файлам, обычно выполняемым путем назначения прав доступа к группам пользователей или ролям.
Потребитель, зритель или гость – человек, который читает или иным образом воспринимает контент после публикации или совместного использования.