Difference between revisions of "IntraACL/ru"
| Line 63: | Line 63: | ||
</div> | </div> | ||
| − | == | + | == Использование == |
| − | + | Все определения прав, групп и т. п. хранятся как вики-страницы в специальном пространстве имён <tt>ACL</tt>. | |
| − | + | Полностью совместим интерфейс для расширений (по сути, состоящий из одного метод <tt>Title::userCanReadEx()</tt>). | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Большинство идентификаторов и соглашений по именованию в коде оставлены неизменными — мы не хотим побыстрее забыть свои корни (как в Эстонии — «у наас теперь самый умный тот, кто побыстрее русский язык забудет»). | |
| − | + | Терминология на данный момент общая с предком (<tt>HaloACL</tt>): | |
| − | + | === SD (Security Descriptor) === | |
| − | Права | + | Права для чего-нибудь. Чем-нибудь может быть страница, категория, пространство имён. В Semantic MediaWiki чем-нибудь также может быть свойство (''property''). |
| − | + | SD сохраняются как вики-страницы в пространстве имён ACL: | |
| + | * Права на пространство имён - <tt>ACL:Namespace/'''ИмяПространстваИмён'''</tt>. | ||
| + | * Права на категорию - <tt>ACL:Category/'''ИмяКатегории'''</tt>. | ||
| + | * Права на страницу - <tt>ACL:Page/'''ПространствоИмён:ИмяСтраницы'''</tt>. "ПространствоИмён:" пусто для страницы из основного пространства имён. | ||
| − | + | Права переопределяющие: | |
| + | * Права на категорию переопределяют права на пространство имён. | ||
| + | * Права на несколько категорий суммируются. | ||
| + | * Права на страницу переопределяют все остальные. | ||
| − | Также | + | Также есть настройка доступа по умолчанию к тем статьям, на которые не распространяется действие ни одного SD - <tt>$haclgOpenWikiAccess</tt>. Если оно <tt>= true</tt>, к таким статьям разрешён полный доступ для всех пользователей, если <tt>= false</tt> - доступ запрещён для всех пользователей, кроме администраторов и бюрократов (Wiki-групп "sysop" и "bureaucrat"). |
| − | + | SD может включать в себя IR (''Inline Rights''), включение других SD или PR (''Predefined Rights'') и права на изменение самого SD. | |
| − | + | Синтаксис IR - см. ниже. | |
| − | + | Синтаксис включений: | |
| − | ==== PR (Predefined right или Right template) | + | <nowiki>{{</nowiki>#predefined right: assigned to = User:'''ИмяПользователя''', Group/'''ИмяГруппы'''}} |
| + | |||
| + | Синтаксис прав изменения самого SD: | ||
| + | |||
| + | <nowiki>{{</nowiki>#manage rights: assigned to = User:'''ИмяПользователя''', Group/'''ИмяГруппы'''}} | ||
| + | |||
| + | === PR (Predefined right или Right template) === | ||
Шаблон прав, ничего конкретно не защищающий. По структуре совпадает с SD. Его можно включать в другие шаблоны или в SD, и тогда права, определённые в нём, распространяются на то, куда он включён. | Шаблон прав, ничего конкретно не защищающий. По структуре совпадает с SD. Его можно включать в другие шаблоны или в SD, и тогда права, определённые в нём, распространяются на то, куда он включён. | ||
| − | + | Сохраняются как страницы желательно с именами вида <tt>ACL:Right/'''ИмяШаблона'''</tt>, но также и как любые страницы в пространстве ACL, не попадающие под остальные шаблоны имён. | |
| + | |||
| + | === IR (Inline right) === | ||
«Базовая единица» прав — «одно право». Имеет две характеристики: | «Базовая единица» прав — «одно право». Имеет две характеристики: | ||
| Line 104: | Line 114: | ||
Доступны следующие права: | Доступны следующие права: | ||
| − | * | + | * Чтение (read), запись (edit), удаление (delete), переименование (move). |
| − | + | * Создание новых статей (create) - в пространстве имён или категории. | |
| − | + | * Полный доступ (*) - эквивалентен "чтение+запись+удаление+переименование+создание". | |
| − | + | * Изменение прав статей (manage) - наследуется статьями от включаемых ими SD/PR и от SD/PR категории или пространства имён, если у статьи нет своего SD. Отличается от прав на изменение SD, которые в редакторе называются "изменение шаблона прав" и не наследуется никем, кто бы ни включал этот SD. Подробнее см. [[#Право manage]]. | |
| − | * | + | |
| − | * | + | |
| − | + | Синтаксис IR: | |
| − | + | <nowiki>{{</nowiki>#access: assigned to = User:'''ИмяПользователя''', Group/'''ИмяГруппы''' | actions = *, read, write, create, delete, move, manage}}</pre> | |
| − | + | == Отличия от HaloACL == | |
| + | |||
| + | Немного статистики: Diffstat diff’а -NaurpBb между оригиналом HaloACL и IntraACL: | ||
| + | |||
| + | * Без учёта YUI, пакованных скриптов, картинок — удалено файлов: 36, строк: 15387. | ||
| + | * YUI + пакованные скрипты — удалено файлов: 33, строк: 33606. | ||
| + | * Картинки — удалено файлов: 39, добавлено: 1. | ||
| + | * Изменено файлов: 28, строк: +5126/-11568. | ||
| + | * Добавлено файлов: 24, строк: 5483. | ||
| + | |||
| + | Предыдущие данные, видимо, были некорректны, была попытка сосчитать статистику по сумме всех изменений из svn. Эти тоже надо ещё проверить :) | ||
| − | + | === Редактор === | |
[[File:HaloACL ACL Editor.png|thumb|right|200px|Редактор прав HaloACL]] В HaloACL интерфейс служебной страницы реализован неудобно, глючит и тормозит, на основе JavaScript-фреймворка YAHOO UI ''(в жизни к нему теперь не притронусь)''. Кроме того, он переусложнён ''(можно написать раз в 5 меньше кода)'', и ужасен с точки зрения удобства пользователя — он пошаговый и не очень интерактивный. | [[File:HaloACL ACL Editor.png|thumb|right|200px|Редактор прав HaloACL]] В HaloACL интерфейс служебной страницы реализован неудобно, глючит и тормозит, на основе JavaScript-фреймворка YAHOO UI ''(в жизни к нему теперь не притронусь)''. Кроме того, он переусложнён ''(можно написать раз в 5 меньше кода)'', и ужасен с точки зрения удобства пользователя — он пошаговый и не очень интерактивный. | ||
| Line 123: | Line 141: | ||
[[File:IntraACL ACL Editor.png|thumb|right|200px|Редактор прав IntraACL]] В IntraACL интерфейс гораздо дружелюбнее и написан на «голом» JavaScript’е, без использования каких-либо фреймворков вообще (кроме МедиаВиковского AJAX’а — sajax_do_call), посему работает очень шустро и приятно. Аналогично реализован и редактор групп, и списка шаблонов быстрого доступа. | [[File:IntraACL ACL Editor.png|thumb|right|200px|Редактор прав IntraACL]] В IntraACL интерфейс гораздо дружелюбнее и написан на «голом» JavaScript’е, без использования каких-либо фреймворков вообще (кроме МедиаВиковского AJAX’а — sajax_do_call), посему работает очень шустро и приятно. Аналогично реализован и редактор групп, и списка шаблонов быстрого доступа. | ||
| − | + | ==== Пример ==== | |
Пример создания прав в редакторе HaloACL: | Пример создания прав в редакторе HaloACL: | ||
| Line 153: | Line 171: | ||
* Кнопка «Сохранить» ровно одна :) | * Кнопка «Сохранить» ровно одна :) | ||
| − | + | === Панель === | |
Переделана панель, появляющаяся при редактировании страниц: | Переделана панель, появляющаяся при редактировании страниц: | ||
| Line 164: | Line 182: | ||
** какие шаблоны и изображения использованы на странице и на каких страницах они ещё использованы, и даёт возможность легко распространить защиту на них. | ** какие шаблоны и изображения использованы на странице и на каких страницах они ещё использованы, и даёт возможность легко распространить защиту на них. | ||
| − | + | === Кросс-линковка === | |
В оригинальном HaloACL есть проблема с лёгким доступом к определениям и обратно, так как практически нигде нет ссылок. В IntraACL наоборот, они практически везде есть — например, ссылки со страницы на соответствующий ей ACL, с ACL на соответствующую ему страницу и на интерактивный редактор, и так далее. | В оригинальном HaloACL есть проблема с лёгким доступом к определениям и обратно, так как практически нигде нет ссылок. В IntraACL наоборот, они практически везде есть — например, ссылки со страницы на соответствующий ей ACL, с ACL на соответствующую ему страницу и на интерактивный редактор, и так далее. | ||
| − | ==== Право manage | + | === Упрощения === |
| + | |||
| + | Убраны права на «добавление семантических аннотаций», «редактирование через форму», «редактирование через WYSIWYG-редактор» (ну что за бред — разрешать править статью через WYSIWYG, но не разрешать просто), ибо приравнены просто к праву редактирования. | ||
| + | |||
| + | Убраны такие понятия, как «Личный шаблон по умолчанию» (Default user template), «Белый список» (Whitelist). Первое потому, что неудобно в одном месте задавать шаблон по умолчанию, а в другом — список шаблонов, доступных для быстрого выбора на панельке. Удобно в общем списке выбирать тот, который будет по умолчанию. Второе потому, что «белый список» только усложняет проверки — на страницы можно просто раздать права на чтение, что будет эквивалентно. | ||
| + | |||
| + | Убрана возможность перевода названий функций парсера и их параметров, ибо нефиг разводить 1С («Если (хаха) то (хаха) КонецЕсли»). Названия всегда на английском. | ||
| + | |||
| + | Разрешено включать не только шаблоны прав (PR), но и дескрипторы (SD). | ||
| + | |||
| + | === Право manage === | ||
В оригинальном HaloACL права на изменение самих прав задаются неудобно — отдельной функцией парсера, и ни в коем случае не наследуются от включаемых шаблонов. Соответственно, невозможно просто взять и создать SD для страницы, включающий один шаблон и больше ничего, так как его никто не сможет изменить. | В оригинальном HaloACL права на изменение самих прав задаются неудобно — отдельной функцией парсера, и ни в коем случае не наследуются от включаемых шаблонов. Соответственно, невозможно просто взять и создать SD для страницы, включающий один шаблон и больше ничего, так как его никто не сможет изменить. | ||
| Line 185: | Line 213: | ||
* Аналогично с шаблонами прав (PR). Если этот текст — часть шаблона прав (PR), '''actions=manage''' даст пользователю Someone право редактировать права (SD) страниц, в SD которых включён этот шаблон, но не даст ему редактировать шаблон. В то же время, '''manage rights''' даст Another права редактировать шаблон (PR), но никак не отразится на его правах редактирования SD страниц, в которые этот шаблон включён. | * Аналогично с шаблонами прав (PR). Если этот текст — часть шаблона прав (PR), '''actions=manage''' даст пользователю Someone право редактировать права (SD) страниц, в SD которых включён этот шаблон, но не даст ему редактировать шаблон. В то же время, '''manage rights''' даст Another права редактировать шаблон (PR), но никак не отразится на его правах редактирования SD страниц, в которые этот шаблон включён. | ||
| − | === | + | === Рефакторинг кода === |
| − | + | Огромный объём рефакторинга. Например, константы перемещены из отдельных классов в общий, локализация упрощена, функции парсера более не полагаются на то, что при сохранении статья будет parse’иться, а также позволяют массовое редактирование и импорт/экспорт (то есть редактирование нескольких страниц за запрос). Разрешается изменение некорректных определений, дабы если что, пользователям не приходилось тут же бежать к админам. | |
| − | + | [[en:IntraACL/en]] | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Revision as of 19:46, 2 September 2011
IntraACL — лучшее расширение для MediaWiki, связанное с поддержкой прав доступа к страницам 8-). Требует патча в код MediaWiki. Создано на основе отлаженного и очень сильно допиленного HaloACL.
- Домашняя страница: http://wiki.4intra.net/IntraACL
- Лицензия: GPLv3
- Copyright (c) 2010+, Vitaliy Filippov, Stas Fomin
- Copyright 2009, ontoprise GmbH
- Обзор кода
Введение
Права в MediaWiki — общая ситуация
MediaWiki is not designed to be a CMS, or to protect sensitive data. To the contrary, it was designed to be as open as possible. Thus it does not inherently support full featured, air-tight protection of private content. But with the massive increase of MediaWiki use in corporate intranets and the many CMS-like features emerging, demand for tighter security is emerging.
Как всем известно, MediaWiki проектировалась как движок для Wikipedia. А Википедия открытая, ей права не нужны. Даже наоборот, принцип WikiWiki именно в том, чтобы разрешить максимально лёгкую правку всем, не говоря уже про чтение.
Поэтому архитектура MediaWiki не рассчитана на защиту чего-то от кого-то, кроме правки от анонимусов. Существует множество механизмов, с помощью которых защиту от просмотра можно обойти (включения страниц, свежие правки и т. п.), особенно с учётом возможной установки любого из 1700+ расширений, каждое из которых может осуществлять прямой доступ к БД (и хорошо, что может, а то ворочалась бы вики, как прочий неторопливый «ынтырпрайз»).
Примеры подобных механизмов описаны здесь: Security issues with authorization extensions, плюс есть страница со сравнением существующих механизмов защиты, с которой мы и узнали про HaloACL.
HaloACL и в оригинале уже решает практически все эти проблемы. Однако, когда мы попробовали его поиспользовать, оказалось, что у него свои недостатки — огромное число багов и неторопливая работа интерфейсов (спасибо YAHOO UI). Пришлось сначала дорабатывать, а когда доработки зашли слишком далеко — давать собственное название и форкать.
Фичи IntraACL
- Интерактивный редактор прав доступа (спецстраница).
- Возможность создания страниц вместе с защитой.
- Защита страниц.
- Защита категорий.
- Защита пространств имён.
- Защита семантических свойств — не протестирована и почти наверняка разломана в процессе доработки.
- Возможность включения прав друг в друга.
- Определения прав доступа на вики-страницах в специальном пространстве имён.
- Группы пользователей, возможность включения групп в группы. Не стандартный MediaWiki-механизм групп (sysop, bureaucrat и т. п.), а собственный механизм, группы хранятся также на вики-страницах.
- Возможность лёгкой защиты включаемого в статью содержимого.
Защита механизмов доступа
На странице Security issues with authorization extensions описаны следующие механизмы, которые для тех или иных реализаций прав доступа могут представлять собой «дыру». Относительно IntraACL их статус следующий:
- ✓ Включение страниц — если страница недоступна для чтения, всё выглядит так, как будто её нет. Есть глобальная переменная-настройка, позволяющая вместо «красных ссылок» тихо включать пустой текст.
- ✓ Предзагрузка текста — при правке с другой страницы — текст заменяется на «доступ запрещён».
- ✓ Экспорт/импорт — недоступные статьи не экспортируются и не могут быть перезаписаны импортом.
- ✓ Ленты свежих правок — недоступные статьи не отображаются в лентах.
- ✓ Списки, поиск — аналогично, в списках недоступных статей нет.
- ✓ Diff’ы, история
- ✓ api.php?action=query
- ✓ Сырой/печатный вид
- ✓ Связанные права
- ✓ Доступ не даётся создателю неявно (это немного странно).
- ✓ Кэширование
- ✓ Перенаправления
- ✓ Правка секций
- ✓ Другие расширения — если совместимы с IntraACL/HaloACL. Все расширения из состава Mediawiki4Intranet — совместимы.
- ✓ Слежение за страницами — если пользователь раньше следил за страницей, а потом она была закрыта, сообщения о её изменениях ему больше не придут.
- ✓ Перемещение страниц — если переместить защищённую страницу, права будут перемещены вместе с ней, а старая страница получит права, равные включению прав новой, для защиты «свежих правок» (!).
- ✕ Прямой доступ к содержимому загруженных файлов — пока что не защищается, так как требует интеграции прав с веб-сервером.
Использование
Все определения прав, групп и т. п. хранятся как вики-страницы в специальном пространстве имён ACL.
Полностью совместим интерфейс для расширений (по сути, состоящий из одного метод Title::userCanReadEx()).
Большинство идентификаторов и соглашений по именованию в коде оставлены неизменными — мы не хотим побыстрее забыть свои корни (как в Эстонии — «у наас теперь самый умный тот, кто побыстрее русский язык забудет»).
Терминология на данный момент общая с предком (HaloACL):
SD (Security Descriptor)
Права для чего-нибудь. Чем-нибудь может быть страница, категория, пространство имён. В Semantic MediaWiki чем-нибудь также может быть свойство (property).
SD сохраняются как вики-страницы в пространстве имён ACL:
- Права на пространство имён - ACL:Namespace/ИмяПространстваИмён.
- Права на категорию - ACL:Category/ИмяКатегории.
- Права на страницу - ACL:Page/ПространствоИмён:ИмяСтраницы. "ПространствоИмён:" пусто для страницы из основного пространства имён.
Права переопределяющие:
- Права на категорию переопределяют права на пространство имён.
- Права на несколько категорий суммируются.
- Права на страницу переопределяют все остальные.
Также есть настройка доступа по умолчанию к тем статьям, на которые не распространяется действие ни одного SD - $haclgOpenWikiAccess. Если оно = true, к таким статьям разрешён полный доступ для всех пользователей, если = false - доступ запрещён для всех пользователей, кроме администраторов и бюрократов (Wiki-групп "sysop" и "bureaucrat").
SD может включать в себя IR (Inline Rights), включение других SD или PR (Predefined Rights) и права на изменение самого SD.
Синтаксис IR - см. ниже.
Синтаксис включений:
{{#predefined right: assigned to = User:ИмяПользователя, Group/ИмяГруппы}}
Синтаксис прав изменения самого SD:
{{#manage rights: assigned to = User:ИмяПользователя, Group/ИмяГруппы}}
PR (Predefined right или Right template)
Шаблон прав, ничего конкретно не защищающий. По структуре совпадает с SD. Его можно включать в другие шаблоны или в SD, и тогда права, определённые в нём, распространяются на то, куда он включён.
Сохраняются как страницы желательно с именами вида ACL:Right/ИмяШаблона, но также и как любые страницы в пространстве ACL, не попадающие под остальные шаблоны имён.
IR (Inline right)
«Базовая единица» прав — «одно право». Имеет две характеристики:
- кому выдано — это набор пользователей и/или набору групп (не вики-групп, а IntraACL-групп).
- что выдано — набор прав.
Доступны следующие права:
- Чтение (read), запись (edit), удаление (delete), переименование (move).
- Создание новых статей (create) - в пространстве имён или категории.
- Полный доступ (*) - эквивалентен "чтение+запись+удаление+переименование+создание".
- Изменение прав статей (manage) - наследуется статьями от включаемых ими SD/PR и от SD/PR категории или пространства имён, если у статьи нет своего SD. Отличается от прав на изменение SD, которые в редакторе называются "изменение шаблона прав" и не наследуется никем, кто бы ни включал этот SD. Подробнее см. #Право manage.
Синтаксис IR:
{{#access: assigned to = User:ИмяПользователя, Group/ИмяГруппы | actions = *, read, write, create, delete, move, manage}}</pre>
Отличия от HaloACL
Немного статистики: Diffstat diff’а -NaurpBb между оригиналом HaloACL и IntraACL:
- Без учёта YUI, пакованных скриптов, картинок — удалено файлов: 36, строк: 15387.
- YUI + пакованные скрипты — удалено файлов: 33, строк: 33606.
- Картинки — удалено файлов: 39, добавлено: 1.
- Изменено файлов: 28, строк: +5126/-11568.
- Добавлено файлов: 24, строк: 5483.
Предыдущие данные, видимо, были некорректны, была попытка сосчитать статистику по сумме всех изменений из svn. Эти тоже надо ещё проверить :)
Редактор
В HaloACL интерфейс служебной страницы реализован неудобно, глючит и тормозит, на основе JavaScript-фреймворка YAHOO UI (в жизни к нему теперь не притронусь). Кроме того, он переусложнён (можно написать раз в 5 меньше кода), и ужасен с точки зрения удобства пользователя — он пошаговый и не очень интерактивный. В IntraACL интерфейс гораздо дружелюбнее и написан на «голом» JavaScript’е, без использования каких-либо фреймворков вообще (кроме МедиаВиковского AJAX’а — sajax_do_call), посему работает очень шустро и приятно. Аналогично реализован и редактор групп, и списка шаблонов быстрого доступа.
Пример
Пример создания прав в редакторе HaloACL:
- Сначала нужно выбрать, что создаём — права, шаблон, или «личный шаблон».
- Потом выбрать на что создаём права — на страницу, категорию, namespace, свойство. Опция «свойство» не скрывается, даже если Semantic MediaWiki не установлена.
- Ввести имя и нажать «Далее». После этого поменять имя, естественно, уже нельзя.
- Нажать «Create right». Откроется страшная форма с кучей полей.
- Ввести имя и описание для «права». То есть словесное описание. Зачем оно — понятия не имею.
- Выбрать права галочками.
- Выбрать «кому» из 5 вариантов («мне», «набору юзеров/групп», «всем», «всем зарегистрированным», «всем анонимным»).
- Выбрать галочками, кому же всё-таки, в случае набора. Выбор ведётся из YUI TreeView, фильтруемого тут же, и со страшной силой тормозит.
- Чтобы просмотреть, кому что-то выдано сейчас, надо переключиться на другую вкладку.
- После этого нажать «Сохранить право». Но если вы думаете, что квест закончен и всё сохранилось, очень ошибаетесь.
- Нажать «Далее».
- Ещё одной такой же формочкой задать права на изменение самих прав.
- Нажать «Далее».
- Нажать «Сохранить».
Только после этого ваши права сохранятся. При всём этом процессе увидеть, какие реально получились права с учётом всех включений шаблонов и групп нельзя. Также нельзя увидеть реальный текст определения, который в действительности сохранится на страницу прав. Также в оригинале плохо работает и само сохранение — иногда оно сохраняет текст определения, но не разбирает его на права и они в итоге не действуют.
В IntraACL, с другой стороны, редактор интерактивный, не пошаговый и всегда показывает то, что будет сохранять.
- В любой момент можно поменять, что защищаем, добавить права, права на изменения прав или включения шаблонов.
- Везде работает автозаполнение (autocomplete) — подсказывает страницы, пространства имён, категории, пользователей, группы.
- При выборе пользователя или группы состояние флажков (✓) меняется так, чтобы отражать текущие права выбранного пользователя/группы.
- Причём, редактор подгружает включаемые определения групп и шаблонов и вычисляет реальные права, учитывая, если право было дано пользователю, потому что он находится в группе или если право дано через шаблон.
- Дать или отобрать права очень легко — нужно просто отметить или снять флажок. Текст определения прав при этом изменится.
- Кнопка «Сохранить» ровно одна :)
Панель
Переделана панель, появляющаяся при редактировании страниц:
- Не требует тяжёлого JavaScript’а.
- Сохраняет состояние при нажатии «Предпросмотра».
- Показывает ссылки на шаблоны быстрого доступа, чтобы можно было просмотреть их содержимое.
- Подсказывает,
- какие ещё права действуют на страницу (то есть права на пространства имён и категории).
- когда вы не можете редактировать права страницы.
- какие шаблоны и изображения использованы на странице и на каких страницах они ещё использованы, и даёт возможность легко распространить защиту на них.
Кросс-линковка
В оригинальном HaloACL есть проблема с лёгким доступом к определениям и обратно, так как практически нигде нет ссылок. В IntraACL наоборот, они практически везде есть — например, ссылки со страницы на соответствующий ей ACL, с ACL на соответствующую ему страницу и на интерактивный редактор, и так далее.
Упрощения
Убраны права на «добавление семантических аннотаций», «редактирование через форму», «редактирование через WYSIWYG-редактор» (ну что за бред — разрешать править статью через WYSIWYG, но не разрешать просто), ибо приравнены просто к праву редактирования.
Убраны такие понятия, как «Личный шаблон по умолчанию» (Default user template), «Белый список» (Whitelist). Первое потому, что неудобно в одном месте задавать шаблон по умолчанию, а в другом — список шаблонов, доступных для быстрого выбора на панельке. Удобно в общем списке выбирать тот, который будет по умолчанию. Второе потому, что «белый список» только усложняет проверки — на страницы можно просто раздать права на чтение, что будет эквивалентно.
Убрана возможность перевода названий функций парсера и их параметров, ибо нефиг разводить 1С («Если (хаха) то (хаха) КонецЕсли»). Названия всегда на английском.
Разрешено включать не только шаблоны прав (PR), но и дескрипторы (SD).
Право manage
В оригинальном HaloACL права на изменение самих прав задаются неудобно — отдельной функцией парсера, и ни в коем случае не наследуются от включаемых шаблонов. Соответственно, невозможно просто взять и создать SD для страницы, включающий один шаблон и больше ничего, так как его никто не сможет изменить.
Вместе с тем и делать, чтобы все права на изменение прав наследовались, тоже не очень правильно — нужно различать «управление правами страницы» и «управление шаблоном». То есть, хотелось бы иметь возможность выдать в шаблоне кому-нибудь права на управление страницей, но при этом не выдавать права на управление самим шаблоном.
В IntraACL это возможно — есть дополнительное право «manage» в составе обычной парсер-функции access, которое и является «правом на управление страницей», но не действует на шаблон. Пример использования:
{{#access: assigned to = User:Someone | actions = *, manage}}
{{#manage rights: assigned to = User:Another}}
В чём же различие между actions=manage и manage rights?
- Если этот текст — часть прав (SD) страницы, разницы нет. Пользователи Someone и Another получат права на изменение этого SD.
- Если этот текст — часть прав (SD) категории или пространства имён, actions=manage даст пользователю Someone право редактировать права (SD) страниц, находящихся в этой категории или пространстве имён, но не даст прав на изменение SD самой этой категории или пространства имён. В то же время, manage rights даст Another права редактировать SD категории/пространства имён, но никак не отразится на его правах редактирования SD страниц.
- Аналогично с шаблонами прав (PR). Если этот текст — часть шаблона прав (PR), actions=manage даст пользователю Someone право редактировать права (SD) страниц, в SD которых включён этот шаблон, но не даст ему редактировать шаблон. В то же время, manage rights даст Another права редактировать шаблон (PR), но никак не отразится на его правах редактирования SD страниц, в которые этот шаблон включён.
Рефакторинг кода
Огромный объём рефакторинга. Например, константы перемещены из отдельных классов в общий, локализация упрощена, функции парсера более не полагаются на то, что при сохранении статья будет parse’иться, а также позволяют массовое редактирование и импорт/экспорт (то есть редактирование нескольких страниц за запрос). Разрешается изменение некорректных определений, дабы если что, пользователям не приходилось тут же бежать к админам.
