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

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

Основанный на ролях подход - это уход от подхода, основанного на уровнях, который мы использовали в 1.5 и [который используется] по умолчанию в конфигурации ACL [списка контроля доступа] 2.5. Подумайте над традиционными группами автор->редактор->публикующий. За исключением случаев, когда деловые правила требуют [ввести в действие] ограничение, чтобы редактор всегда был автором и публикующий всегда был редактором, то нет необходимости в таком наследовании как это. Вместо этого, каждый должен разделять [группу] Public как свою родительскую, предоставляя нам возможность назначать пользователя любой конфигурации этих трех независимых ролей. Кто сказал что публикующий должен быть всегда автором!

Основанный на ролях подход пересекает линию, которую основанный на уровнях подход принимает как границу и которую стирает [версия] 2.5.

По мере того, как мы применяем роли, мы свободно создаем новые группы и уровни доступа, устанавливаем сравнительно плоскую иерархию нашим новым группам и скупо назначаем права. Внутри структуры, основанной на уровнях, эти практики кажутся неверными. Для вдохновения нам нужно взглянуть за пределы конфигурации традиционного ACL [списка контроля доступа]. Вот подход по применению ролей в Joomla.

Определите те роли, которые нужны Вашему клиенту

Определите обязанности в системе, которые имеют тенденцию к тому, что они будут либо разделены между пользователями, либо их могут переместить от одного пользователя к другому. Хорошим начальным моментом будет сфокусироваться на каждом компоненте и поразмыслить, не следует ли создать роль только для этого. Это, возможно, является слишком упрощенным, но поскольку роли часто связаны с отдельным компонентом, это хороший момент для начала. И, конечно, иногда какая-либо роль может быть ответственна за множество компонентов или только за несколько частей сложного компонента. Когда Вы действительно определяете какую-либо роль, определяйте ее в условиях и размере, которые будут понятны тем, кто будет управлять данным веб-сайтом и его содержимым.

Создайте какую-либо группу для каждой роли

Для представления роли мы будем использовать группу пользователей [системы] Joomla. Каждая роль представлена своей собственной группой. Если Вы определили двенадцать ролей, то Вы будете добавлять двенадцать новых групп пользователей. Каждая группа будет присваивать набор прав и доступ, которые уникальны для этой роли - ничего более, ничего менее. Названием, которое Вы будете использовать для этой группы, будет название роли, которое [Ваш] клиент будет видеть при назначении пользователей ролям, так что выбирайте интуитивное название, даже если для него потребуются несколько слов.

Выровняйте иерархию этой группы

Большинство ролей будут родственниками другим ролям и иерархия будет неглубокой. Это отличается от группового наследствования, которое мы увидели в 1.5 и 2.5, где родственные группы редки и наследствование по линии - обычное дело. По контрасту, большинство основанных на ролях групп будут разделять одного и того же родителя, поскольку большинство ролей являются независимыми от других ролей и назначить пользователя любой комбинации ролей без [их] пересечений и конфликтов должно быть возможным.

Предположите, что основанные на ролях группы будут родственниками друг другу, но помните, что две обычные причины борются за дополнительный уровень наследия: 1) когда несколько групп разделяют какой-либо набор прав или какой-либо уровень доступа, то имеет смысл создать родительскую группу, которая представляет эти разделенные права или доступ. 2) когда какая-либо роль должна включать все права и доступ другой роли и затем раcширяться на их основании, то эта расширенная роль должна наследовать у своей базовой роли.

Обычно, несколько ролей будут требовать доступа к административной панели и это является хорошей причиной для создания родительской группы, которая позволяет вход в административную панель. Все роли административной панели будут разделять ее как свою родительскую. Какая-либо группа, которая предоставляет доступ к административной панели, требует внимания к двум настройкам. Первая, пройдите в общие настройки и установите права для этой группы [так], чтобы разрешить вход в административную панель. Вторая, если Вы захотите показать административное меню этим пользователям (для некоторых веб-сайтов Вы не захотите), то Вам нужно добавить эту новую группу к уровню доступа "Special". (Почему? Это административное меню настроено на уровень доступа "Special", и Вы отвечаете за то, чтобы добавлять любую создаваемую Вами группу к подобающим уровням доступа.)

Роли, которые не требуют доступа к админстративной панели, могут разделять "Public" или "Registered" как своего родителя, или, если Вы находите это более интуитивным, Вы можете создать группу под названием "Роли лицевой части веб-сайта", чисто в целях сбора под одной отдельной родительской группой всех ролей лицевой части веб-сайта.

Назначьте права по одной роли

Какая-либо типичная роль будет ограничена только до одного компонента. Для каждой основанной на роли группы, пройдите в связанный с ней компонент(ы) и предоставьте необходимые права только этой основанной на роли группе. Далеко не редкость когда какой-либо компонент предоставляет права только супер администратору, администратору и одной основанной на ролях группе. Фактически, вполне резонно будет отозвать ранее назначенные администратору (и даже супер администратору) права, оставляя ту основанную на ролях группу как единственную группу назначаемую эти права.

Создайте основанный на ролях уровень доступа

Здесь будет очень полезно понять как уровни доступа вписываются в ACL [список контроля доступа]. [Говоря] механически, уровень доступа - это ничего более чем некоторое группирование групп пользователей. В применении, уровень доступа представляет критерий, который какой-либо пользователь должен удовлетворить чтобы [можно было] определить является ли данный пользователь членом данного уровня доступа (и таким образом заслуживает доступ). Модули, пункты меню, плагины, категории и даже сам каждый объект должны быть назначены какому-либо уровню доступа. Это назначение - это фактически назначение правила, которое инструктирует [систему] Joomla относительно показывать ли [ей] данный объект или запускать ли в работу данный плагин - косвенно на основании назначения группы пользователя.

Возможно подлежит спору что будет лучше назвать слабо поименованный "уровень доступа" как "правило доступа". Хотя набор уровней доступа по умолчанию (Public, Registered и Special) настроен чтобы представлять три слоя, представляющие "уровни", в 2.5 нет ничего присущего уровням доступа, которые назначают уровни. Какой-либо уровень доступа провозглашает только набор групп (в любой комбинации и без осознания уровней).

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

Подход к наименованию поможет нам управлять тем, что может стать далеко не тривиальным списком. Я создаю каждому основанному на ролях уровню доступа приставку "~". Поскольку уровни доступа перечисляются в списках по алфавиту, это помогает упаковать основанные на ролях уровни доступа в одну группу и отделять ее от традиционного набора (Public, Registered и Special).

Сократите Ваш ACL [список контроля доступа]

Сокращение - это практика взять что-либо без необходимости усложненное и длинное и упростить это. В математике, мы сокращаем 15/25 до 3/5. В программировании мы берем длинный код и упрощаем его с целью выполнять то же самое [что этот код выполнял до нашего его упрощения], но с меньшим числом строк и так, чтобы с этим кодом было легче работать.

Здесь [с ACL], мы оцениваем созданные нами группы и уровни доступа и ищем как их можно разумно упростить. Возможно, какой-либо набор групп требует, чтобы какая-либо новая группа была общим для некоторых родителем для того, чтобы делиться правами или уровнем доступа. Возможно, некоторые основанные на ролях уровни в действительности не нужны, или существует необходимость объединить один или несколько [из них] в [один] единый уровень доступа. Если все прекрасно работает, Вам не нужно сокращать, но сокращение Вашего ACL [списка контроля доступа] может привести к конфигурации, которая является более интуитивной.

Административные модули

Одной из крупнейших выгод основанного на ролях подхода является то, что те кто управляет данным веб-сайтом через [его] административную панель смогут увидеть контрольную панель, которая показывает [им] только то, к чему им нужен доступ. Административное меню не должно показывать [то], на работу с чем у данного пользователя нет прав. Мощным приемом для индивидуальной подстройки административной панели является создание административных модулей, по одному на кажду роль, и назначение каждого из этих модулей соответствующему основанному на ролях уровню доступа. Каждый из этих модулей может содержать информацию или ссылки [иконки] быстрого вызова, которые показаны только кому-либо назначенному на этот уровень доступа. Административная панель будет показывать только те модули, которые соответствуют назначенным этому пользователю ролям. Давайте проиллюстрируем это ниже.

Назначение пользователей ролям

Это на нашей ответственности, как интеграторов веб-сайтов, создать и настроить роли, которые соответствуют [тому], как [данная] компания понимает каждую роль. Если мы выполним это хорошо, то тогда то, что мы сдаем нашим клиентам - это очень интуитивная система для управления назначением ролей. Это простой проверочный список ролей, каждая индивидуально поименована и назначает права, которую любой ожидал. Именно так просто оно и есть.

То, что может не быть немедленно явно, [так] это нужда в роли "управляющего пользователями". Эта особая роль предоставляет возможность создавать пользователей, подстраивать настройки и назначать основанные на ролях группы. Преданно философии основанного на ролях, эта роль позволяет нам предоставлять кому-либо права для управления пользователями и без необходимости повышать их до администратора. Не забывайте создавать эту роль.

Заключение

Чтобы укрепить этот простой подход, вот Вам простые шаги для создания роли менеджера пользователей.

1. Создайте новую группу. Назовите ее "управление пользователями". Ее родителем должна быть группа, которая предоставляет права на административную панель. Если у Вас нет такой группы, создайте эту родительскую группу и дайте этому родителю право на вход в административную панель и добавьте ее к уровню доступа "Special".
2. Назначьте необходимые права. В административной панели пройдите на страницу менеджера пользователей и выберите [в правом верхнем углу страницы кнопку] "Настройки". В разделе "Менеджер пользователей (и только в этом разделе), разрешите все права, за исключением "Настраивать".
3. Уровни доступа. В этом случае нам не нужен основанный на ролях уровень доступа, поскольку главное меню автоматически покажет его тем, у кого есть права на доступ к нему. Однако, если Вы желаете предоставить какие-либо административные модули которые будут показаны только менеджерам пользователей, то тогда Вам будет нужно создать для этой роли уровень доступа основанный на ролях.
4. Назначьте этой роли какого-либо пользователя. Затем протестируйте свои настройки. Войдите как этот пользователь в административную панель и понаблюдайте за простотой, [которую] мы создали для управления пользователями.

Эта статья предоставила быстрый подход к настройке ролей в [системе] Joomla. Это не трудно, но применение основанного на ролях ACL [списка контроля доступа] действительно требует нового взгляда. Вы готовы к этому? 

Примечание переводчика: эта статья - вторая из серии статей автора Рэнди Кэри (Randy Carey) по ACL системы Joomla. Не зубудьте познакомиться с переводом первой статьи, "Доказательство основанного на ролях ACL [списка контроля доступа]".