IntraACL/ru

What links here (1) →

IntraACL — расширение MediaWiki.

• Назначение: Лучшее расширение для MediaWiki для поддержки постраничных прав доступа. Требует патча в код MediaWiki. Сильно развитый форк HaloACL.
• Репозиторий: https://github.com/mediawiki4intranet/IntraACL
• Домашняя страница: http://wiki.4intra.net/IntraACL 
• Версия MediaWiki: гарантирована совместимость с 1.19-1.25, возможна с другими 
• Авторы: Vitaliy Filippov & Stas Fomin. Based on HaloACL by ontoprise GmbH, 2009.
• Лицензия: GPLv3.0+ 
• Дата создания: 2010-09-03 
• Последняя версия: 2.1.8 
• Оценка расширения: Очень полезное (5)

Включение в сборку Mediawiki4Intranet:

• Дата включения: 2010-09-03
• Включённая версия: последняя
• Состояние доработок: Создано в рамках MediaWiki4Intranet

Введение

Права в 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 — совместимы.
• ✓ Слежение за страницами — если пользователь раньше следил за страницей, а потом она была закрыта, сообщения о её изменениях ему больше не придут.
• ✓ Перемещение страниц — если переместить защищённую страницу, права будут перемещены вместе с ней, а старая страница получит права, равные включению прав новой, для защиты «свежих правок» (!).

• ✓ Доступ не даётся создателю неявно (что, вообще-то, немного странно).
• ✓ Прямой доступ к содержимому загруженных файлов — защищается с помощью img_auth.php

• ✕ Защита семантических свойств не поддерживается.

Использование

Все определения прав, групп и т. п. хранятся как вики-страницы в специальном пространстве имён ACL.

Интерфейс для расширений

ЛЮБОЕ установленное совместно с IntraACL расширение может являться потенциальной причиной УТЕЧКИ ДАННЫХ. Вы должны убедиться, что все установленные у вас расширения проверяют доступ к статье перед тем, как отображать что-то, с ней связанное, с помощью описанных ниже методов. Либо же вы можете пользоваться сборкой Mediawiki4Intranet: расширения из её состава доступ проверяют.

Интерфейс простой — почти никаких новых методов не предоставляется, расширения лишь должны делать проверки прав методом $title->userCanRead() (для MediaWiki 1.18 и ниже) или $title->userCan('read') (для MediaWiki 1.19 и выше) перед показом содержимого, связанного со страницей, заданной объектом Title $title.

Начиная с версии 2.1.0, IntraACL также поддерживает фильтрацию страниц внутри СУБД путём вызова хранимой процедуры. Это нужно, во-первых, чтобы ускорить выборку большого числа страниц из базы данных с проверкой прав, а во-вторых, для корректной разбивки списков статей на страницы. Чтобы задействовать этот механизм, нужно использовать хук FilterPageQuery:

// Ваш запрос к БД - параметры аналогичны отправляемым в метод Database::select()
$query = array(
    'tables'     => $tables,
    'fields'     => $fields,
    'conds'      => $conds,
    'options'    => $options,
    'join_conds' => $join_conds
);
 
// Алиас фильтруемой таблицы со статьями в запросе
// Если такой таблицы в $tables ещё нет, она будет туда добавлена
$page_alias = 'page';
// Параметры LEFT JOIN для добавляемой таблицы страниц (если нужно добавлять)
$page_join_conds = array();
// NULL или целочисленный номер пространства имён, если известно,
// что все выбираемые страницы находятся в одном и том же пространстве имён
$override_namespace = NULL;
 
// Следующий вызов модифицирует ваш запрос, чтобы он возвращал только страницы,
// видимые текущему пользователю:
wfRunHooks('FilterPageQuery', array(&$query, $page_alias, $page_join_conds, $override_namespace));

Быстрый старт

Установите и подключите расширение.

Защита страницы

Попробуйте закрыть правами какую-нибудь страницу:

• Откройте любую страницу. Вы увидите вкладку «ACL» между вкладками «статья» и «обсуждение». Кликните на неё.
• Кликните «Создать редактором». Вы увидите редактор IntraACL.
• Кликните в поле ввода рядом с выпадающим списком, в котором выбран «Пользователь», и начните набирать имя какого-нибудь пользователя — вы увидите подсказку.
• Остановите свой выбор на каком-нибудь существующем пользователе кликом по его имени в подсказке.
• Нажмите на флажок «Полный доступ».
• Вы можете добавить ещё нескольких пользователей, так же выбирая их и кликая по нужным флажкам.
• Нажмите «Сохранить».

Теперь вашу страницу смогут прочитать только выбранные пользователи. Обратите внимание, что со страницы определения прав вы можете перейти обратно к странице кликом по вкладке «статья».

Защита категории

Вы можете сделать аналогичную операцию с категорией — тогда защиту получит как сама категория, так и все страницы, находящиеся в ней:

• Перейдите на страницу категории.
• Нажмите «ACL», нажмите «Создать редактором».
• Аналогично добавьте нужных пользователей и права, нажмите «Сохранить».

По умолчанию права в IntraACL «аддитивные», то есть, если вы защитите отдельно страницу и включите её в защищённую категорию, доступ получат и пользователи, указанные в правах на страницу, и пользователи, указанные в правах на категорию. То же самое верно и для пространств имён. Поменять это поведение можно через конфигурацию.

Защита пространства имён

И всё то же самое можно проделать с целым пространством имён, однако, заходить в редактор потребуется со списка спецстраниц:

• Нажмите «Спецстраницы» в левой панели, из длинного списка выберите «IntraACL».
• Кликните по вкладке «Создать новый ACL».
• В поле «Цель защиты» выберите «Защищить пространство имён».
• Поставьте курсор в поле ввода — вы увидите список пространств имён. Выберите из него нужное вам кликом.
• Дальше ваши действия совершенно аналогичны — добавьте пользователей/права и сохраните ACL.

Просмотр и удаление ACL

• Нажмите «Спецстраницы» в левой панели, из длинного списка выберите «IntraACL».
• Перед вами список созданных определений прав. Кликнув по какому-то из них, вы снова попадёте в редактор.
• Чтобы удалить какое-то определение, нажмите «Удалить», и подтвердите удаление. Удалённые права более не будут применяться к странице.

Терминология

Терминология на данный момент общая с предком (HaloACL):

SD (Security Descriptor)

Права для чего-нибудь. Чем-нибудь может быть: страница, категория, пространство имён.

SD сохраняются как вики-страницы в пространстве имён ACL:

• Права на пространство имён — ACL:Namespace/ИмяПространстваИмён ("ACL:Namespace/Main" для основного пространства имён).
• Права на категорию — ACL:Category/ИмяКатегории.
• Права на страницу — ACL:Page/ПространствоИмён:ИмяСтраницы. «ПространствоИмён» — пустое для страницы из основного пространства имён, а для остальных является НЕлокализованным именем.

Есть несколько режимов работы, а именно — суммирование/переопределения/сужение прав. В случае переопределения:

• Права на категорию переопределяют права на пространство имён.
• Права на несколько категорий суммируются.
• Права на страницу переопределяют все остальные.

В случае суммирования — все применённые к странице права суммируются, в случае сужения — все они пересекаются. Режим работы устанавливается в конфигурации, и по умолчанию равен суммированию.

Также есть настройка доступа по умолчанию к тем статьям, на которые не распространяется действие ни одного SD — $haclgOpenWikiAccess. Если оно = true, к таким статьям разрешён полный доступ для всех пользователей, если = false — доступ запрещён для всех пользователей, кроме администраторов и бюрократов (Wiki-групп «sysop» и «bureaucrat»).

SD может включать в себя отдельные права (IR — Inline Rights), либо другие SD или PR (Predefined Rights) и права на изменение самого SD.

Синтаксис IR — см. ниже.

Синтаксис включений:

{{#predefined right: ACL:Page/Страница | ACL:Right/Default}}

Синтаксис прав изменения самого 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}}

«Все пользователи»: {{#access: assigned to = *}}.

«Зарегистрированные пользователи»: {{#access: assigned to = #}}.

Группы

Группа пользователей. Может включать пользователей или другие группы, и права на изменение группы.

Синтаксис включений пользователей/групп:

{{#member: members = User:ИмяПользователя, Group/ИмяГруппы }}

Синтаксис прав на изменение группы:

{{#manage group: assigned to = User:ИмяПользователя, Group/ИмяГруппы }}

Панель IntraACL

При редактировании и создании вики-страниц отображается дополнительная панель IntraACL:

Она включает в себя:

• Поле выбора прав доступа для страницы. В нём перечисляются текущий SD страницы и шаблоны (PR) быстрого доступа, выбранные вами в редакторе на странице «Шаблоны быстрого доступа» (см. ниже). При изменении выбранного SD и дальнейшем сохранении страницы её права изменяются. Важно, что шаблоны быстрого доступа можно выбрать и при создании новой статьи — тогда она с самого начала будет защищена.
• Ссылка «Связанное содержимое ↓» — при клике по ней появляется всплывающее окошко со списком файлов и включённых статей, использованных на данной. Если они при этом используются и на других, будет выведено примечание — «на N страницах». Напротив каждого файла/статьи есть флажок — если установить какие-то флажки и сохранить страницу, этот файл/статья будет защищён теми же правами, что и текущая статья. Предыдущие права на этот файл будут перезаписаны.
• Ссылка «Править редактором» на изменение ACL текущей статьи с помощью IntraACL-редактора.
• Ссылка «Шаблоны быстрого доступа» на редактирование списка ваших PR, используемых в этой панели.

Редактор прав

Интерактивный редактор прав представлен спецстраницей Special:IntraACL.

Имеет следующие функции:

Список ACL

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

Для каждого SD/PR отображаются ссылки просмотра и изменения. Строки вида «НазваниеSD = ДругоеНазвание» означают, что SD не включает в себя прав сам по себе, а только включает единственный другой SD.

Создать новый ACL

Форма создания SD/PR. На самом деле - она же является и формой редактирования.

Включает в себя следующие поля:

Текст определения

То, что в итоге будет сохранено на странице SD/PR. Можно редактировать напрямую, но проще использовать другие поля.

Цель защиты

Выбор того, к чему относится создаваемый ACL — к странице, категории, пространству имён, или же это вообще PR.

Имя защищаемого элемента

Имя страницы/категории/пространства имён/шаблона прав (PR). При вводе в поле действует подсказка — начните набирать и вам будет предложен список вариантов.

Ссылка под «целью защиты»

Полное имя итоговой страницы SD/PR.

Правка определения

Включает выпадающий список «Пользователь/Группа/Все пользователи/Зарегистрированные пользователи», имя пользователя/группы (опять-таки с подсказками при вводе), и флажки прав, присвоенных выбранному пользователю/группе. Без введённого значения поле имени показывает список пользователей/групп, затронутых редактируемым ACL на данный момент, причём учитываются косвенные включения — через группы и другие включённые права. Для выдачи прав использовать очень просто:

1. Выберите того, кому хотите выдать права — сначала его тип в выпадающем списке, потом имя в поле ввода.
2. Переключение флажков сразу меняет текст определения в соответствии с выбранным набором прав.

Включение других прав

Включение других SD/PR в данный. Для включения введите имя желаемого SD/PR и нажмите «Включить». В поле ввода опять-таки работает подсказка.

Внимание: После внесения изменений не забудьте нажать кнопку «Создать ACL» или «Сохранить ACL».

Шаблоны быстрого доступа

Выбор шаблонов прав (Predefined rights) для панели IntraACL. Любой из них, либо «Без защиты», можно выбрать как шаблон по умолчанию — тогда при создании страниц в панели по умолчанию будет выбран этот шаблон.

Группы

Список групп, фильтруемый по имени, со ссылками на просмотр и редактирование.

Создать группу

Форма создания группы, она же форма редактирования группы. Поля «Члены группы» и «Могут править группу» — все с подсказками. Без введённого значения показывают всплывающий список пользователей/групп, включённых в редактируемую группу на данный момент. При вводе чего-либо появляется всплывающий список пользователей/групп, имеющих введённый фрагмент имени. Список содержит флажки напротив каждого пользователя/группы. Устанавливая или снимая эти флажки, вы включаете/исключаете членов группы. Потом просто нажмите «Сохранить».

Отличия от HaloACL

Основным отличием IntraACL от HaloACL до недавнего времени был полностью переработанный интерфейс. Структура БД, код, отвечающий за хранение и проверку прав, а также сама концепция были идентичны HaloACL, с небольшими исправлениями.

Однако, начиная с версии 2.0 IntraACL также использует переделанный в сторону упрощения, ускорения и повышения надёжности «бэкенд» (систему хранения / проверки прав).

Редактор

Редактор прав HaloACL

В HaloACL интерфейс служебной страницы реализован неудобно, глючит и тормозит, на основе JavaScript-фреймворка YAHOO UI (в жизни к нему теперь не притронусь). Кроме того, он переусложнён (можно написать раз в 5 меньше кода), и ужасен с точки зрения удобства пользователя — он пошаговый и не очень интерактивный.

Редактор прав IntraACL

В IntraACL интерфейс гораздо дружелюбнее и написан на «голом» JavaScript’е, без использования каких-либо фреймворков вообще (кроме МедиаВиковского AJAX’а — sajax_do_call), посему работает очень шустро и приятно. Аналогично реализован и редактор групп, и списка шаблонов быстрого доступа.

Пример

Пример создания прав в редакторе HaloACL:

1. Сначала нужно выбрать, что создаём — права, шаблон, или «личный шаблон».
2. Потом выбрать на что создаём права — на страницу, категорию, namespace, свойство. Опция «свойство» не скрывается, даже если Semantic MediaWiki не установлена.
3. Ввести имя и нажать «Далее». После этого поменять имя, естественно, уже нельзя.
4. Нажать «Create right». Откроется страшная форма с кучей полей.
5. Ввести имя и описание для «права». То есть словесное описание. Зачем оно — понятия не имею.
6. Выбрать права галочками.
7. Выбрать «кому» из 5 вариантов («мне», «набору юзеров/групп», «всем», «всем зарегистрированным», «всем анонимным»).
8. Выбрать галочками, кому же всё-таки, в случае набора. Выбор ведётся из YUI TreeView, фильтруемого тут же, и со страшной силой тормозит.
9. Чтобы просмотреть, кому что-то выдано сейчас, надо переключиться на другую вкладку.
10. После этого нажать «Сохранить право». Но если вы думаете, что квест закончен и всё сохранилось, очень ошибаетесь.
11. Нажать «Далее».
12. Ещё одной такой же формочкой задать права на изменение самих прав.
13. Нажать «Далее».
14. Нажать «Сохранить».

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

В 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 страниц, в которые этот шаблон включён.

Несколько режимов перекрытия прав доступа

В HaloACL права «аддитивные», то есть более специфичные права (например, права на страницы) всегда расширяют менее специфичные (например, права на целое пространство имён). Это значит, что если пользователю разрешено смотреть всё пространство имён, у него уже нельзя отобрать право смотреть какие-то отдельные статьи из этого пространства имён.

В конфигурации IntraACL, в то же время, можно выбрать один из трёх режимов перекрытия прав доступа:

Расширение прав

Аналогично HaloACL.

Сужение прав

Например, если пользователю дано право смотреть пространство имён, а для отдельной статьи из этого пространства имён заданы собственные права, то для просмотра статьи человеку нужно будет иметь и право на просмотр пространства имён, и право на просмотр отдельной страницы.

Перекрытие прав

Права на отдельные страницы переопределяют права на неймспейсы, категории и т. п.

Варианты прав от наименее специфичных к наиболее специфичным (нижние в списке будут перекрывать/сужать/расширять верхние):

1. Права на пространство имён.
2. Права на категорию, в которую включена статья.
3. Для страниц категорий («Категория: Что-нибудь»): права на саму категорию.
4. Права на собственно страницу.

Выбор пока что устанавливается только для целой вики, а не для отдельных статей (TODO).

Удалена защита семантических свойств

Изначально расширение HaloACL содержит в себе возможность отдельной защиты семантических свойств. Причём, так как оные хранятся и могут быть запрошены отдельно от страниц, защита реализована с помощью большого костыля — шифрования значений свойств, хранящихся в БД.

Рефакторинг кода

Огромный объём рефакторинга — переделано практически всё. Как интерфейс (кодовая бомба примерно на +10000/-15000 строк), так и система хранения и доступа к БД (в ветке storage-rewrite, примерно +4400/-6600 строк).